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AVANT-PROPOS 

James Hendler, directeur de la 
collection « Synthesis Lectures on 
The Semantic Web : Theory and 
Technology » 



En 2009, j'ai invite Aaron Swartz a contribuer par un « expose de synthese » - 
essentiellement un court livre en ligne - a une nouvelle collection que je dirigeais 
sur Pingenierie web. Aaron redigea un brouillon d'environ 40 pages, le document 
que vous voyez ici. C'etait une « premiere version » a completer plus tard. 
Malheureusement, et a mon grand regret, cela n'eut jamais lieu. 

La version fournie par Aaron n'etait pas censee etre le produit fini. II Pa ecrite 
relativement vite, et nous Pa envoyee pour commentaires. Je lui en ai envoye une 
petite serie, et plus tard Frank van Harmelen, qui m'avait rejoint en tant que 
codirecteur de la collection, lui en envoya une serie plus longue. Aaron echangea 
avec nous un petit peu, mais ensuite passa a d'autres choses et ne put terminer. 

A la mort d'Aaron en janvier 2013, nous avons decide qu'il serait benefique de 
publier cela, pour que les gens puissent lire dans ses propres mots ses idees sur la 
programmation du Web, son ambivalence a propos de differents aspects de la 
technologie du Web semantique, quelques pensees concernant Pouverture, etc. 
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Ce document a ete produit originellement au format « markdown », un format 
HTML/Wiki simplifie qu'Aaron avait con^u avec John Gruber autour de 2004. 
Nous avons utilise un des nombreux outils markdown disponibles sur le Web pour le 
convertir en HTML, puis successivement en LateX et en PDF, pour realiser ce 
document. Cette version fut egalement editee pour corriger quelques erreurs de 
copier/coller et ameliorer sa lisibilite. Une version HTML de l'original est 
disponible sur http://www.cs.rpi.edu/~hendler/ProgrammableWebSwartz2009.html. 

En hommage a Aaron, Michael Morgan de Morgan & Claypool, l'editeur de la 
collection, et moi avons decide de publier ce texte librement et gratuitement. Cette 
oeuvre est placee par Morgan & Claypool Publishers sous licence CC-BY-NC-SA. 

Merci d'attribuer l'oeuvre a son auteur, Aaron Swartz. 

Jim Hendler, Fevrier 2013 
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Chapitre 1 

Introduction : un Web programmable 



Si vous etes comme la plupart des gens que je connais (et, puisque vous lisez ce 
livre, vous Petes probablement - du moins de ce point de vue), vous utilisez le 
Web. Beaucoup. En fait, dans mon cas personnel, la grande majorite de mes 
journees sont passees a lire ou survoler des pages web - un balayage le long de 
mon client webmail pour parler avec amis et collegues, un blog ou deux pour me 
tenir au courant des infos du jour, une douzaine d'articles courts, une flottille de 
requetes Google, et le va-et-vient permanent vers Wikipedia pour une reponse 
isolee a une question persistante. 

Que du bon, bien sur ; en fait, du presque indispensable. Et ^a fait reflechir quand 
on pense qu'il y a un peu plus d'une decennie, rien de tout n'existait. Les emails 
avaient leur propres applications specialises, les blogs n'avaient pas encore ete 
inventes, les articles se trouvaient sur papier, Google n'etait pas ne, et Wikipedia 
meme pas une etincelle distante dans l'oeil de Larry Sanger. 

Du coup, il est saisissant, presque choquant en fait, d'imaginer ce a quoi le monde 
pourra ressembler quand nos logiciels iront sur le Web aussi frequemment et aussi 
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facilement que nous. Aujourd'hui, bien sur, nous pouvons voir les pales et futurs 
miroitements d'un tel monde. II y a des logiciels qui appellent chez eux pour voir 
s'il y a une mise a jour. II y a des logiciels dont une partie du contenu - la page 
d'aide, peut-etre, ou une sorte de catalogue - est diffusee en ligne sur le Web. II y a 
des logiciels qui envoient une copie de tout votre travail pour le stocker sur le 
Web. II y a des logiciels specialement concus pour vous aider a naviguer sur un 
certain type de page web. II y a des logiciels qui ne sont rien d'autre qu'un certain 
type de page web. II y a des logiciels - qu'on appelle « mashups » - qui consistent 
en une page web qui combine les informations des deux autres pages web. Et il y a 
des logiciels qui, par l'intermediaire d'« APIs », traitent d'autres sites web 
simplement comme un autre morceau de 1' infrastructure du logiciel, une autre 
fonction qu'ils peuvent appeler pour faire des choses. 

Nos ordinateurs sont tellement petits et le Web est tellement grand et vaste que ce 
dernier scenario semble faire partie d'une tendance irresistible. Pourquoi ne 
compteriez-vous pas sur d'autres sites a chaque fois que vous le pouvez, faisant 
ainsi de leurs informations infinies et de leurs abondantes capacites une partie 
homogene du votre ? Et je pressens que de tels usages deviendront de plus en plus 
communs jusqu'a ce qu'un jour votre ordinateur soit aussi ligote au Web que vous 
l'etes vous-meme aujourd'hui. 

II est parfois suggere qu'un tel futur est impossible, que fabriquer un Web que 
d'autres ordinateurs pourraient utiliser est le fantasme de quelques auteurs de 
science-fiction (a mon avis, sans trop d' imagination). Que cela ne pourrait 
arriver que dans un monde de robots lourds, d' intelligence artificielle et de 
machines qui vous suivent en aboyant des ordres tout en, par intermittence, 
tentant de vous convaincre sans succes d'acheter une nouvelle paire de 
chaussures. 

II n'est done peut-etre pas si surprenant que l'un des detracteurs qui ont exprime 
ce genre de point de vue, Cory Doctorow, soit justement un auteur de science- 
fiction plutot imaginatif (entre autres choses). II expose sa critique dans son essai 
« Metamerde : mettons le feu a sept epouvantails de la meta-utopie egalement 
edite dans son recueil d'essais « Contenu : essais choisis sur la technologie, la 
creativite, le droit d' auteur et le futur du futur »( 2) , lui aussi disponible en ligne 
(http://craphound.com/content/download/). 



2 



Chapitre 1 - Introduction : un Web programmable 

Doctorow affirme que tout systeme tentant de collecter des « metadonnees » 
precises - le type de donnees utilisables par les machines qui seront necessaires 
pour realiser ce reve d'ordinateurs-utilisant-le-web - se heurtera a sept problemes 
insurmontables : les gens mentent, les gens sont faineants, les gens sont betes, les 
gens ne se connaissent pas eux-memes, les schemas ne sont pas neutres, les unites 
de mesure influencent les resultats, et il y a plus d'une fa^on de decrire quelque 
chose. A la place, Doctorow propose qu'au lieu d'essayer d'obtenir des gens qu'ils 
produisent des donnees, nous devrions regarder les donnees qu'ils produisent 
fortuitement en faisant autre chose (comme Google, qui regarde les liens que les 
gens font quand ils ecrivent des pages web), et utiliser plutot celles-la. 

Doctorow, bien sur, s'attaque a un epouvantail. Le fantasme utopique de donnees 
honnetes, completes et non-biaisees sur absolument tout est irrealisable. Mais qui 
tentait qa, en fait ? Le Web est rarement parfaitement honnete, complet et impartial 
- et pourtant il est sacrement utile. II n'y a pas de raison qu'on ne puisse pas faire 
un Web utilisable par les ordinateurs de la meme maniere. 

Je dois dire toutefois que les promoteurs de l'idee sont un peu coupables de ces 
perceptions utopistes. Beaucoup d'entre eux ont se sont repandus a propos du 
« Web semantique » au sein duquel nos ordinateurs seront enfin capables de 
« comprehension par les machines ». Un tel cadrage (parmi d'autres facteurs) a 
attire les refugies du monde de 1' intelligence artificielle, qui tire le diable par la 
queue, et ceux-ci ont trouve la une nouvelle opportunite de promouvoir l'oeuvre de 
leur vie. 

Au lieu de 1' attitude « construisons simplement quelque chose qui marche » qui a 
fait du Web (et d'Internet) un tel succes, ils ont amene l'etat d'esprit normalisateur 
des mathematiciens et les structures institutionnelles des universitaires et des 
fournisseurs de la Defense. Ils ont forme des comites pour former des groupes de 
travail pour ecrire des brouillons d'ontologies (des documents Word de 100 pages) 
qui listent precisement toutes les choses possibles dans l'univers et les proprietes 
variees qu'elles peuvent avoir, et ils ont passe des heures en debats talmudiques 

1 « Metacrap : Putting the torch to seven straw-men of the meta-utopia » [non-traduit en francais]. 
Disponible en ligne : http://www.well.com/~doctorow/metacrap.htm. 

2 « Content: Selected Essays on Technology, Creativity Copyright, and the Future of the Future » 
(2008, Tachyon Publications) [non-traduit en francais]. 
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sur le fait qu'un lave-vaisselle soit un appareil electromenager de cuisine ou de 
nettoyage. 

Avec eux sont arrives les recherches universitaires, les subventions 
gouvernementales, les R&D du prive, et tout 1' appareil des gens et des institutions 
qui ont un projet chimerique. Et au lieu de passer du temps a fabriquer des choses, 
ils ont convaincu les personnes interessees par ces idees que le premier besoin 
etait d'ecrire des standards (aux yeux des ingenieurs, c'est absurde des le debut - 
les standards sont ce qu'on ecrit apres qu'on a obtenu quelque chose qui 
fonctionne, pas avant !). 

Du coup, le groupe « Semantic Web Activity » du World Wide Web Consortium 
(W3C) a passe son temps a ecrire standard sur standard : le langage de balisage 
extensible (Extensible Markup Language / XML), la structure de description des 
ressources (Resource Description Framework / RDF), le langage d'ontologie Web 
(Web Ontology Language / OWL), des outils pour la recolte de descriptions de 
ressources a partir de dialectes de langages (Gleaning Resource Descriptions from 
Dialects of Languages / GRDDL), le protocole simple et langage de requete RDF 
(Simple Protocol And RDF Query Language / SPARQL), cree par le groupe de 
travail RDF sur Faeces aux donnees (RDF Data Access Working Group / DAWG). 

Peu d'entre eux sont utilises de maniere largement repandue, et ceux qui le sont 
(XML) sont invariablement les fleaux de la planete, des offenses faites aux 
programmeurs travailleurs qui ont repousse des formats senses (comme JSON) en 
faveur d'usines a gaz sur-compliquees absolument pas basees sur la realite (Et je 
n'en ai pas fini ! - plus la-dessus au chapitre 5). 

Au lieu de faire parler des systemes existants entre eux et de consigner les 
meilleures pratiques, ces garants auto-proclames du Web semantique ont passe 
leur temps a creer leur propre petit univers, complete par des bases de donnees en 
Web semantique et des langages de programmation. Mais les bases de donnees et 
les langages de programmation, meme tres imparfaits, sont des problemes 
largement resolus. Les gens ont deja leurs preferes, qui ont ete testes et bricoles 
pour fonctionner dans toutes sortes d'environnements inhabituels, et ils ne sont 
pas particulierement enclins a en apprendre un nouveau, surtout sans une bonne 
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raison de le faire. C'est assez difficile de faire en sorte que les gens partagent des 
donnees telles quelles, encore plus difficile de les faire les partager dans un format 
particulier, et completement impossible d'obtenir qu'ils les conservent et les 
administrent dans un systeme totalement nouveau. 

Et pourtant c'est a quoi les grosses tetes du Web semantique passent leur temps. 
C'est comme si pour amener les gens a utiliser le Web ils avaient commence par 
ecrire un nouveau systeme d' exploitation avec le Web directement construit en 
son coeur. Bien sur, il y a des chances qu'on en arrive la un jour, mais insister pour 
que les gens commencent par qa aurait confine le Web dans l'obscurite des le 
premier jour. 

Tout cela a conduit les « ingenieurs web » (comme le titre de cette collection les 
nomme affectueusement) a faire la sourde oreille et a retourner a un vrai travail, 
parce qu'ils ne voulaient pas perdre leur temps avec des choses qui n' existent 
pas et qui, fort probablement, n'existeront jamais. Et qa a conduit beaucoup de 
ceux qui avaient travaille sur le Web semantique, dans le vain espoir de 
reellement construire un monde ou les logiciels pourraient communiquer, a 
craquer, tout plaquer et trouver des voies plus productives auxquelles consacrer 
leur attention. 

Par exemple, voyez Sean B. Palmer. Dans son article remarque « Laisser tomber le 
Web semantique ? » (3) , il proclame : « II n'est pas prudent, et peut-etre meme pas 
moral (si cela ne sonne pas trop melodramatique), de travailler sur RDF, OWL, 
SPARQL, RIF, l'idee cassee de confiance distribute, CWM, Tabulator, Dublin 
Core, FOAF, SIOC, ni sur tout ce genre de choses ». Et, non seulement il va 
« arreter de travailler sur le Web semantique » mais il va « en outre, activement 
dissuader tout le monde de travailler sur le Web semantique, s'empechant ainsi de 
travailler sur » des projets plus pratiques. 

En toute justice, notons bien que je ne suis pas exactement un observateur 
impartial. D'abord, Sean, a l'instar d'a peu pres toutes les personnes que je cite 
dans ce livre, est un ami. Nous nous sommes rencontres quand nous travaillions 

3 « Ditching the Semantic Web? » [non-traduit en francais]. Disponible en ligne : 
http://inamidst.com/whits/2008/ditching. 
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ensemble sur ces sujets, et depuis nous avons garde contact, nous echangeons des 
emails sur ce sur quoi nous travaillons en ce moment, et nous sommes 
generalement gentils Tun envers l'autre. C'est le cas pour presque toutes les autres 
personnes que je cite et critique. 

De plus, la raison pour laquelle nous avons travaille ensemble, c'est que j'ai aussi 
fait mon temps dans les mines de sel du Web semantique. Ma premiere application 
web etait une encyclopedic collaborative, mais ma deuxieme, des gros titres 
agreges de sites d'information repartis sur le Web, m'a entraine dans une spirale 
descendante qui s'acheva, apres de nombreuses annees passees dans les groupes 
de travail du noyau RDF par une decision definitive de m' eloigner du monde de 
l'mformatique dans son ensemble. 

Manifestement, n'a pas marche tout a fait comme prevu. Jim Hendler, un autre 
ami, et un de ces transfuges de 1' Intelligence artificielle sur qui je viens de taper 
longuement, m'a demande si je pouvais ecrire un petit quelque chose sur le sujet 
pour entamer une nouvelle collection de livres electroniques qu'il est en train de 
lancer. Je ferais n'importe quoi pour un peu d'argent (je plaisante : je veux juste 
etre publie (je plaisante : j'ai deja ete publie plein de fois (je plaisante : pas tant de 
fois que qa (je plaisante : je l'ai ete, mais j'ai besoin de m'entrainer (je plaisante : 
je ne m'entraine jamais (je plaisante : je voulais juste publier un livre (je plaisante : 
je voulais juste ecrire un livre (je plaisante : c'est facile d'ecrire un livre (je 
plaisante : c'est un chemin de croix (je plaisante : c'est pas si mal (je plaisante : ma 
copine m'a quitte (je plaisante : je l'ai quittee (je plaisante, je plaisante, je 
plaisante))))))))))))) et done me revoila, reprenant ces vieilles questions, avec enfin 
une occasion de me plaindre a propos de l'erreur que les gens du Web semantique 
avaient faite. 

Cependant, comme mon petit exercice de pensee exprime plus haut l'a je l'espere 
demontre, le Web programmable est tout sauf une chimere - c'est la realite 
d'aujourd'hui et la banalite de demain. Aucun developpeur de logiciels ne se 
contentera de se limiter aux choses presentes sur l'ordinateur de l'utilisateur. Et 
aucun developpeur de site web ne se contentera de limiter son site aux seuls 
utilisateurs qui interagissent directement avec lui. 
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Tout comme le pouvoir a" inter-liaison du World Wide Web a aspire tous les 
documents disponibles dans son gosier - encourageant les gens a les numeriser, a 
les convertir en HTML, a leur donner une URL, et a les mettre sur Internet (bon 
sang, pendant que nous parlons Google le fait meme pour des bibliotheques 
entieres) - le Web programmable engloutira toutes les applications a portee de 
main. Les benefices du fait d'etre connecte sont simplement trop puissants pour 
qu'on puisse resister. 

Bien entendu, ce sera - comme toutes les nouvelles technologies - un defi ouvert 
pour les modeles economiques, particulierement pour ceux qui font leur argent sur 
l'enfermement et Faeces payant aux donnees. Mais de telles pratiques ne sont tout 
simplement pas viables sur le long terme, legalement comme d'un point de vue 
pratique (encore moins moralement). D'apres la loi des Etats-Unis, les faits ne 
sont pas soumis au droit d'auteur (grace a la decision de la Cour supreme faisant 
jurisprudence dans l'affaire Feist v. Rural Telephone Service) et les bases de 
donnees sont juste des collections de faits (quelques pays europeens ont des droits 
speciaux pour les bases de donnees, mais de telles extensions ont ete fermement 
ref usees aux Etats-Unis). 

Et meme si la loi ne s'en mele pas, il est tellement avantageux de partager des 
donnees que la plupart des fournisseurs de donnees vont probablement y venir. 
Evidemment, fournir un site web ou les gens peuvent passer chercher des choses 
peut etre tres rentable, mais n'est rien en comparaison de ce qui est possible 
quand on combine ces informations avec d'autres. 

Pour prendre un exemple tire de ma propre carriere, voyez le site web 
OpenSecrets.org. II collecte des informations concernant les donateurs aux 
candidats politiques des Etats-Unis, et presente de jolis graphiques et tableaux sur 
les industries qui ont finance les campagnes des candidats a la presidentielle et des 
membres du Congres. 

De la meme maniere, le site web Taxpayer.net fournit une profusion 
d'informations sur les provisions congressionnelles - des demandes de 
financement que des membres du Congres glissent dans les projets de lois, 
reclamant quelques millions de dollars pour quelqu'un pour sa marotte 
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personnelle (le « pont pour nulle-part » a 398 millions de dollars en etant le plus 
fameux exemple^). 

Tous les deux sont des sites fantastiques et sont utilises frequemment et a profit par 
les observateurs de la politique americaine. Mais imaginez combien meilleurs ils 
seraient si vous les reunissiez - vous pourriez chercher les principaux 
contributeurs a des campagnes qui ont re^us des grosses subventions. 

Notez que ce n'est pas le genre de « remix » qu'on peut realiser avec les APIs 
d'aujourd'hui. Les APIs permettent seulement de regarder les donnees d'une 
certaine fa^on, generalement de la fa^on dont le site hebergeur les regarde. Ainsi, 
avec l'API d'OpenSecrets, on peut obtenir une liste des contributeurs les plus 
importants d'un candidat. Mais n'est pas suffisant pour le type de question qui 
nous interesse - il nous faut comparer chaque subvention avec chaque donateur et 
chercher les concordances. Cela necessite un acces reel aux donnees. 

Notez aussi qu'en fin de compte, le resultat final est avantageux pour tout le 
monde. OpenSecrets.org veut que les gens en sachent plus sur l'influence 
problematique de l'argent sur la politique. Taxpayer.net veut attirer l'attention sur 
ces depenses inutiles. Le public veut savoir comment l'argent en politique entraine 
des depenses inutiles, et un site qui les y aiderait servirait l'objectif des deux 
organisations. Mais elles ne peuvent y parvenir qu'en acceptant de partager leurs 
donnees. 

Heureusement pour nous, le Web a ete con^u avec ce futur a l'esprit. Les 
protocoles sur lesquels il est fonde ne sont pas simplement concus pour fournir des 
pages a la consommation humaine, mais egalement pour accueillir facilement la 
menagerie des araignees, des robots et des scripts qui explorent son sol fertile. Et 
les developpeurs originels du Web, les hommes et les femmes qui ont invente les 
outils qui en font le passe-temps chronophage qu'il est aujourd'hui, se sont depuis 
longtemps interesses a rendre le Web sur, et meme accueillant, pour les 
applications. 



4 [http://en.wikipedia.org/wiki/Gravina_Island_Bridge]. 
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Malheureusement, trop peii savent cela, et cela en amene beaucoup a reinventer - 
n'importe comment - le travail qui a deja ete fait (le fait que les rares personnes au 
courant aient passe leur temps a travailler sur cet absurde Web semantique que j'ai 
critique plus haut n'a pas aide). Done nous commencerons par essayer de 
comprendre 1' architecture du Web - ce qui marche bien et, a 1' occasion, ce qui ne 
marche pas, mais surtout pourquoi il est fait comme qa. Nous allons apprendre 
comment il autorise a la fois les utilisateurs et les moteurs de recherche a coexister 
pacifiquement tout en supportant tout, du partage de photos aux transactions 
financieres. 

Nous continuerons en reflechissant a ce que signifie construire un programme au 
sommet du Web - comment ecrire un logiciel qui sert equitablement autant son 
utilisateur immediat que les developpeurs qui veulent construire par-dessus lui. 
Trop souvent, une API est boulonnee au-dessus d'une application existante, apres- 
coup ou comme un morceau completement different. Mais, comme nous le 
verrons, quand une application web est concue proprement, les APIs en decoulent 
naturellement et leur maintenance ne requiert que peu d' efforts. 

Puis nous nous interesserons a ce que signifie pour votre application de n'etre pas 
seulement un autre outil pour les gens et les logiciels, mais une partie de l'ecologie 
- une section du Web programmable. Ce qui implique d'exposer vos donnees a 
etre interrogees, et copiees, et integrees, et ce meme sans autorisation explicite, au 
sein du plus grand ecosysteme de logiciels, tout en protegeant la liberte des 
utilisateurs. 

Enfin, nous conclurons avec une discussion sur cette expression tres galvaudee : 
« Web semantique », et nous tacherons de comprendre ce qu'elle signifie 
vraiment. 

Allons-y. 
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CONSTRUIRE POUR LES UT1USATEURS 
CONCEVDIR LES URLS 



Sur les panneaux d'affichage, les bus, les cartons d'emballage, elles nous epient 
comme des symboles extra-terrestres (esperons-le, de fa^on moins mena^ante) : 
les URLs sont partout. De maniere plus visible, elles apparaissent en haut de la 
fenetre du navigateur quand les gens utilisent votre site web, mais elles 
apparaissent egalement dans une myriade d'autres contextes : dans la barre de 
notifications quand quelqu'un survole un lien avec la souris, dans des resultats de 
recherche, dans des emails, dans des blogs, lues sur des telephones, inscrites sur 
des serviettes de table, listees dans des bibliographies, imprimees sur des cartes de 
visite et des t-shirts et des tapis de souris et des autocollants de pare-chocs. Ce sont 
des petits symboles versatiles. 

De plus, les URLs doivent tenir. Ces t-shirts, ces liens, ces blogs ne disparaitront 
pas parce vous avez decide de reorganiser votre serveur, ou migre vers un 
systeme d' exploitation different, ou ete promu et remplace par un subordonne 
(ou pas reelu). lis tiendront des annees et des annees, done vos URLs doivent 
tenir aussi. 
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En outre, les URLs ne se contentent pas d'exister en tant qu'entites isolees 
(comme « http://exemple.org/repas/bacon.html »). Elles se combinent pour former 
des modeles (« bacon.html », « laitue.html », « tomate.html »). Et chacun de ces 
modeles trouve sa place sur une plus grande arborescence d' interactions (« / », 
« /repas », « /repas/bacon.html »). 

A cause de tout qa, les URLs ne peuvent pas etre des sortes d'effets secondaires ou 
pensees apres-coup, comme certains ont l'air de le souhaiter. Concevoir les URLs 
est la part la plus importante dans la construction d'une application web, et cela 
doit etre fait en premier. Dans leur conception sont encodees toute une serie de 
presomptions implicites concernant ce dont parle votre site, comment il est 
structure, et comment on est cense l'utiliser ; rien que des questions importantes et 
inevitables. 

Malheureusement, de nombreux outils pour fabriquer des applications web 
essayent de vous cacher ces questions, en vous empechant completement de 
concevoir les URLs. A la place, ils presentent leur propre interface au 
programmeur, depuis laquelle ils generent des URLs en fabriquant des nombres 
aleatoires, en stockant des cookies, ou pire encore (de nos jours, avec AJAX et 
Flash, certains ne fournissent plus d'URLs du tout, faisant du site un enfer pour 
quiconque veut envoyer a ses amis un true cool qu'il a trouve). 

Et quand les gens qui utilisent ce genre de logiciels se retrouvent a devoir ecrire 
une URL sur un t-shirt, ou faire un lien vers quelque chose depuis un email, ils 
creent une redirection - une URL speciale dont l'unique but est d'introduire les 
gens dans le systeme cauchemardesque de nombres aleatoires utilise par leur vrai 
site web. Cela resout leur probleme immediat de trouver quoi ecrire sur le t-shirt, 
mais ga ne resout aucun des problemes plus fondamentaux, et ne rend pas 
possible pour quelqu'un d' autre de faire ses propres t-shirts ou d' envoyer ses 
propres emails. 

Si vos outils ne vous permettent pas de concevoir vos URLs, vous avez besoin de 
meilleurs outils. Personne ne s'aviserait de faire du design graphique avec un 
logiciel qui ne permettrait pas de changer de police ou qui peindrait avec une 
brosse qui ne saurait faire que des carres. Pourtant des gens pensent qu'il est 
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parfaitement acceptable de sacrifier le controle sur les URLs, la part la plus 
fondamentale de votre site web. Ca ne Test pas. Procurez-vous de meilleurs 
outils (5) . 

Une fois pourvu d'outils decents, il est temps de commencer a concevoir. 
Commengons par les plus grandes contraintes. Les URLs ne doivent pas changer 
(si elles changent, les anciennes doivent rediriger vers les nouvelles), done elles 
doivent ne contenir que des informations concernant la page qui ne changent 
jamais. En decoulent quelques imperatifs evidents. 

Ceux-ci furent indiques plus notoirement par l'inventeur du Web, Sir Timothy 
John Berners-Lee, OM, KBE, FRS, FREng, FRSA (ne le 8 Juin 1955 a Londres, 
Angleterre). Pendant un conge de Noel miraculeux, en 1990, qui rappelle une des 
annus mirabilis d'Einstein, Tim n'a pas seulement invente les URL, le format 
HTML, et le protocole HTTP, mais il a aussi ecrit le premier navigateur web, le 
premier editeur web WYSIWYG, et le premier serveur web (qa donne envie de lui 
accorder plus de conges de Noel). Bien que, en fait, cela soit un peu redondant, 
etant donne que le premier navigateur web (appele WorldWideWeb) non 
seulement vous permettait de lire des pages web, mais vous permettait aussi de les 
ecrire. L'idee etait que le Web soit un media interactif, avec tout le monde qui 
conserverait son propre carnet de notes de ses trouvailles interessantes, qui 
collaborerait sur des documents avec d'autres personnes, et qui posterait des trues 
qu'il a fait ou qu'il veut partager. 

Editer une page web etait aussi simple que cliquer dessus - vous pouviez 
simplement basculer en mode edition et selectionner et corriger les fautes de 
frappe directement sur la page, comme dans un traitement de texte (vous cliquiez 
sur enregistrer et qa les versait directement sur le serveur). Vous pouviez creer de 
nouvelles pages simplement en ouvrant une nouvelle fenetre, et au lieu de marque- 
pages, vous etiez cense construire des pages web qui gardent trace des sites que 
vous trouviez interessants (le navigateur originel n'avait pas de barre d'adresse, en 
partie pour vous forcer a marquer vos pages comme cela). 

5 Si vous ne savez pas par ou commencer, il y a bien entendu mon propre jeu d'outils, web.py 
(http://webpy.org/), ou encore la plateforme de developpement web en Python Django 
(http ://dj angoproj ect. com/) . 
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C'etait une idee brillante, mais malheureusement c'etait ecrit pour NeXT, un 
obscur systeme d' exploitation (qui deviendra plus tard Mac OS X), et en 
consequence rares sont ceux qui ont pu l'utiliser. A la place, ils ont utilise le clone 
cree par une equipe de l'universite de l'lllinois Urbana-Champaign (UIUC), qui 
n'a jamais integre d'editeur parce que le programmeur Marc Andreessen etait trop 
bete pour reussir a faire de 1' edition avec des images en ligne, ce qui ne posait 
aucun probleme a la version de Tim Berners-Lee. Marc Andreessen a gagne un 
demi milliard de dollars quand le navigateur de l'UIUC est devenu Netscape, alors 
que Berners-Lee a continue a faire du support technique pour une equipe de 
physiciens en Suisse (il deviendra plus tard chercheur au MIT). 




Capture d'ecran de WorldWideWeb 

(http://www.w3.org/History/1994AVWW/Journals/CACM/screensnap2_24c.gif) 
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Resultat, nous ne nous reapproprions ces merveilleuses caracteristiques qu'une 
vingtaine d'annees plus tard, grace a des choses comme les blogs ou Wikipedia. Et 
meme la, c'est beaucoup plus limite que l'interactivite de grande envergure que 
Berners-Lee imaginait. 

Mais tournons la page du passe, et revenons au futur. Sir Tim affirmait que pour 
proteger vos URLs dans le futur, vous deviez suivre quelques principes de base. 
Dans sa declaration de 1998 « Les URIs cools ne changent pas »®, decrite comme 
« une tentative de rediriger l'energie consacree a la quete de coolitude ... vers 
Putilite [et] la longevite », il les a exposes. 

Cependant, je suis en disaccord avec la solution proposee par Tim pour generer 
des URIs cools. II recommande des schemas rigoureusement bases sur la date, 
comme « http://www.w3.org/1998/12/01/chairs ». D'apres ce que j'ai vu, seul le 
W3C a vraiment adopte rigoureusement cette strategic, et quand je m'y suis 
essaye qa n'a donne que laideur et confusion. 

Vous remarquez peut-etre que Tim parle d'URI alors que je parle d'URL. URL, le 
terme original, signifie Uniform Resource Locator - Localisateur Uniforme de 
Ressource. Cela a ete developpe, en meme temps que le Web, pour fournir une 
fa^on coherente de faire reference a des pages web et a d'autres ressources sur 
Internet. Depuis, cependant, qa a ete etendu a une fa^on de faire reference a toutes 
sortes de choses, dont la plupart ne sont pas des pages web, et dont certaines ne 
peuvent meme pas etre « localisees » de maniere automatisee (par exemple, des 
concept abstraits comme « Time magazine »). En consequence, le terme a ete 
change en URI, Uniform Resource Identifier - Identificateur Uniforme de 
Ressource, pour englober cette selection plus large. Je m'en tiens ici au terme 
d'URL, parce qu'il est plus familier, mais nous finirons par evoquer des concepts 
abstraits dans les chapitres suivants. 

Premierement, vos URLs ne doivent pas inclure de details techniques a propos du 
logiciel utilise pour construire le site web, puisque ceci peut changer a tout 
moment. Par consequent, des choses comme « .php » et « .cgi » sont a bannir. Pour 

6 Disponible en ligne : http://www.w3.org/Provider/Style/URI. 
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des raisons similaires, on peut se debarrasser de « .html », de « PHP_SESS_ID », 
et des choses de ce genre. Vous vous assurerez egalement que les noms des vos 
serveurs (par exemple, « www7.exemple.org » ou « platon.exemple.net ») sont 
absents des URLs. Changer de langage de programmation, de format, ou de 
serveur est assez courant ; il n'y a pas de raison que vos URLs dependent de vos 
choix actuels. 

Deuxiemement, on laissera de cote tous les faits concernant la page qui pourraient 
changer. Ca concerne a peu pres tout (son auteur, sa categorie, qui peut la lire, si 
c'est officiel ou un brouillon, etc.), les URLs sont done vraiment limitees au 
concept essentiel de la page, l'essence de la page. Quelle est la chose qui ne peut 
pas changer, qui fait que cette page est cette page ? 

Troisiemement, vous serez tres precautionneux concernant la classification. 
Beaucoup de gens aiment diviser leur site web par sujets, rangeant leurs recettes 
favorites dans le repertoire « /nourriture/ » , leurs histoires liees aux voyages qu'ils 
font dans « /voyages/ », et les trues qu'ils lisent dans « /livres/ ». Mais 
inevitablement ils finissent par avoir une recette qui necessite un voyage ou un 
livre a propos de nourriture, et ils pensent que ^a appartient aux deux categories. 
Ou ils decident que les boissons devraient vraiment etre extraites et avoir leur 
propre section. Ou ils decident simplement de tout reorganises 

Quelle que soit la raison, ils finissent par rearranger leurs fichiers et changer leur 
structure de repertoires, en cassant toutes leurs URLs. Meme si vous rearrangez 
simplement l'apparence du site, cela demande beaucoup de discipline de ne pas 
deplacer les fichiers, plus sans doute que vous n'en aurez. Et mettre au point des 
redirections pour tout est tellement difficile que vous n'allez meme pas vous en 
preoccuper. 

Le mieux, c'est de faire en sorte en amont de ne jamais devoir etre confronte a ce 
probleme en laissant les categories en dehors des URLs. 

Ca fait beaucoup d' interdictions, que diriez-vous de quelques recommandations ? 
Et bien, une fa^on facile d'obtenir des URLs sures, c'est de prendre des nombres. 
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Ainsi, par exemple, votre systeme de blog pourrait simplement assigner a chaque 
article un identifiant sequentiel, et leurs donner des URLs comme : 

http : //www . posterous . com/p/234 

http : //www . posterous . com/p/235 

http : //www . posterous . com/p/236 

Rien de mauvais la-dedans. Cependant, si votre site est un peu plus populaire, les 
identifiants peuvent devenir plutot longs et deroutants : 

http : //livres . exemple . org/b/30283833 

Dans une situation comme celle-ci, vous pouvez encoder les nombres en base 36 
au lieu d'en base 10. En base 36, on utilise toutes les lettres en plus des chiffres, 
mais dans une seule casse, pour qu'il n'y ait pas de confusion concernant le 
passage en majuscules (imaginez quelqu'un lire l'URL au telephone ; c'est 
beaucoup plus simple de dire « ge, cinq, enne, quatre » que « ge minuscule, le 
chiffre cinq, enne majuscule, le chiffre quatre »). 

Pour etre super prudent, vous pouvez allez plus loin et sauter tous les nombres qui 
comportent zero, O, un, L, ou I, etant donne que ces caracteres peuvent souvent 
etre confondus. 

Vous finissez avec des URLs qui ressemblent a : 

http : //livres . exemple . org/b/3j 7is 

et qui sont beaucoup plus courtes. Alors que quatre caracteres en base 10 ne 
peuvent aller que jusqu'a 9999, en base 36 zzzz vaut 1 679 615. Pas mal. 

Un probleme des identifiants numeriques, cependant, c'est qu'ils ne sont pas 
« optimises » pour les moteurs de recherche. Les moteurs de recherche ne 
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regardent pas settlement le contenu de la page pour decider si c'est un bon resultat 
pour la recherche de quelqu'un, ils regardent aussi l'URL a qui, parce qu'elle est 
tres limitee, ils donnent un poids special. Mais si vos URLs sont simplement des 
nombres, il est peu probable qu'eiles correspondent a la requete de quelqu'un sur 
un moteur de recherche, et ce qui reduit les chances qu'elles soient trouvees dans 
les resultats de recherche. Pour remedier a cela, les gens ajoutent du texte apres le 
nombre, comme dans : 

http : //www. hulu . com/watch/17003/saturday -night- live - 
weekend-update- j udy-grimes 

Le texte a la fin fait partie de l'URL, mais il n'est pas utilise pour identifier la 
page. A la place, le systeme regarde seulement le nombre. Un fois qu'il Pa 
recupere, il regarde le litre correspondant au nombre, verifie s'il correspond a 
l'URL, et si ce n'est pas le cas, il redirige les utilisateurs vers la bonne URL. De 
cette maniere, ils peuvent saisir : 

http : //www . hulu . com/watch/17003/ 
voire meme : 

http : //www. hulu . com/watch/17003/c-est-la-que- j - ai-vu- la- 
blague -citee- plus- haut^ 

et quand meme atterrir sur la bonne page. Ca n'est pas parfait, puisque beaucoup 
d'utilisateurs vont penser qu'ils doivent saisir le long texte « saturday-night-live- 
weekend-update-judy-grimes », mais c'est probablement contre-balance par le 

7 II est interessant que, meme si nous lisons habituellement des livres comme des series de bouts 
de papiers rangees de gauche a droite, on fasse encore reference aux choses mentionnees plus tot 
comme si elles etait « plus haut » que les autres (voire « supra », si vous preferez le Latin), 
comme si on lisait tous encore le rouleau brut que Kerouac a sorti de sa machine a ecrire (pour 
plus de details, voir par exemple : 

http://www.npr.org/templates/story/story.php?storyld=11709924). 

Bien entendu, contrairement a mes predecesseurs a machine a ecrire ou a carnet de notes relie, 
j'ecris ceci dans un logiciel de traitement de texte dont l'orientation haut-bas simulee imite 
parfaitement le rouleau materiel de Kerouac. Je suppose que tout cela est cyclique. 
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nombre d'utilisateurs additionnels qui vont vous trouver plus facilement sur les 
moteurs de recherche (dans P ideal, il pourrait y avoir une fa^on dans PURL 
d'indiquer aux humains que le texte supplemental est optionnel, mais je n'ai pas 
encore vu de convention la-dessus ; j 'imagine qu'on espere qu'ils vont remarquer 
le nombre, et comprendre Pidee). 

(Vous noterez que toutes ces URLs sont dans des repertoires, et pas au niveau le 
plus haut. Ca me parait plus propre - je n'aime pas Pidee d'un site dont tous les 
fichiers seraient etales aleatoirement sous le repertoire racine ; c'est bien plus 
agreable d'imaginer tous les fichiers du site empiles dans « /watch/ » ou « /b/ ». 
Mais si vos noms principaux sont eux-memes des sous-repertoires, comme pour 
les pages d'utilisateurs sur Twitter ou Delicious, cela peut faire sens d'enfreindre 
cette regie. On y reviendra bientot.) 

Les nombres fonctionnent bien dans les cas ou les pages sont creees 
automatiquement (parce que vous importez beaucoup de trues, ou vous generez 
des pages en reponse a des emails, ou automatiquement pour d'autres raisons), ou 
quand leurs titres ont tendance a changer, mais dans d'autres cas, vous pouvez 
preferer ce qu'on appelle un « slug ». Un slug est simplement un petit bout de 
texte qui rend bien dans une URL, comme « wrt_dfw » ou « beyond-flash ». 
Quand un utilisateur cree une page, il cree le slug en meme temps (peut-etre avec 
un slug auto-genere par defaut a partir du titre), et ensuite vous le forcez a le 
conserver (ou alors, assurez-vous de rediriger tous les anciens s'il en change). 

Sur les sites comme Wikipedia, les slugs sont generes incidemment. Quand vous 
inserez un texte comme « Jackson n'etait guere admirateur des dernieres oeuvres 
de [[Robert Davidson]] », le site cree automatiquement un lien vers une nouvelle 
page avec le slug « Robert_Davidson ». Grace particulierement aux nombreuses 
conventions sur les titres que Wikipedia a etablies au cours des annees (et grace en 
meme temps aux redirections de sauvegarde infinies), le resultat est etonnamment 
pratique. 

Vous remarquerez que toute cette discussion n'a concerne, au fond, que des noms 
- les choses qui composent principalement votre site, queries qu'elles soient 
(videos, articles de blog, livres). II y a generalement trois autres types de pages : 
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les sous-pages (qui creusent un certain aspect du nom), les pages du site (comme 
« a propos », l'aide, et tout qa), et les verbes (qui vous permettent de faire des 
choses avec les noms. 

Les sous-pages sont a la fois les plus faciles et les plus compliquees. Dans les cas 
simples, vous indiquez simplement la sous-page en ajoutant un slash et un slug 
pour la sous-page. Done si votre page sur Nancy Pelosi est a l'adresse : 

http : //watchdog . net/p/nancy_pelosi 

il semble plutot evident que votre page concernant ses finances devrait etre a 
l'adresse : 

http : //watchdog . net/p/nancy_pelosi/f inances 

Parfois, la majorite de votre site est composee de sous-pages. Ainsi sur Twitter une 
page d'utilisateur est a l'adresse : 

http : //twitter . com/aaronsw 
tandis que leurs messages de statuts ont des URLs de type : 

http : //twitter . com/aaronsw/statuses/918239758 

(On notera que le morceau « statuses » est redondant, et que le nombre est 
beaucoup trop long.) 

Mais les choses se compliquent quand vos noms ont entre eux des relations plus 
complexes. Prenez Delicious, ou les utilisateurs postent des liens sous divers tags. 
Comment cela devrait-il etre structure ? user/link/tag ? tag/user/link ? 

Delicious, qui pendant longtemps a utilise son schema d'URLs comme principale 
interface de navigation, est tellement brillant dans ses choix d'URLs que son etude 
merite toute notre attention. lis ont decide que les utilisateurs etaient l'objet 
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principal, et leur ont donne toute la place dans « / » (comme Twitter). Et sous 
chaque utilisateur, on peut filtrer par tags, on a done : 

http : //delicious . com/aaronsw (mes liens) 

http://delicious.com/aaronsw/video (parmi mes liens, ceux 
tagues « video ») 

http : //delicious . com/aaronsw/video+tech (parmi mes liens, ceux 
tagues « video » et « tech ») 

Et ils ont cree un pseudo-utilisateur special, appele tag, qui vous permet de voir 
tous les liens avec un tag : 

http : //delicious . com/tag/tech (tous les liens tagues « tech ») 

(Les URLs des liens ne sont pas si malines, mais passons la-dessus.) II est difficile 
de donner des regies generates sur comment resoudre ces problemes d'inter- 
liaison ; en gros, vous devez faire ce qui « colle bien » avec votre application. Pour 
les sites sociaux, comme Delicious et Twitter, cela signifie mettre 1' accent sur les 
utilisateurs, puisque e'est principalement ce qui interesse les utilisateurs. Mais 
pour d'autres applications peut etre moins evident. 

II est tentant de tout simplement ne pas decider, et de tout autoriser. Ainsi, a la 
place de Delicious, on aurait : 

http : //del . exemple . org/u/aaronsw (mes liens) 

http : //del . exemple . org/t/tech (tous les liens tagues « tech ») 

http : //del . exemple . org/u/aaronsw/t : tech (parmi mes liens, ceux 
tagues « tech ») 

http://del.exemple.0rg/t/tech/u:aaronsw (les liens tagues 
« tech » parmi mes liens) 
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Le probleme ici est que les deux derniers sont des doublons. II faut vraiment 
choisir une forme et s'y tenir, sinon on finit par perturber les moteurs de recherche, 
les historiques de navigateur, et tous les autres outils qui essayent de garder une 
trace de s'ils ont visite une page ou non. Si vraiment vous avez plusieurs fa^ons de 
parvenir a la meme page, vous devriez en choisir une comme etant l'officielle, et 
vous assurer que toutes les autres sont des redirections (pour pousser a 1' extreme, 
vous prendriez l'exemple « video+tech » d'au-dessus, et le redirigeriez vers 
« tech+video », en faisant de FURL ou les tags sont classes par ordre alphabetique 
FURL officielle). 

Ensuite, les pages de site. En regardant plus haut comment Twitter et Delicious, en 
gros, donnent les cles du magasin (vous voulez dire que je peux avoir 
« twitter.com/contact » si mon nom d'utilisateur est « contact » ?!), vous vous 
demandez peut-etre ou ils peuvent bien mettre leurs pages d'aide ou de connexion. 
Une astuce serait de reserver un sous-repertoire comme « /meta/ », et de tout 
mettre la-dedans. Mais il semble que Delicious et Twitter s'en soient sortis 
simplement en reservant tous les noms de pages potentiels importants, et ils ont 
mis leurs affaires dedans. Done, comme vous vous en doutez, la page de 
connexion est a Fadresse : 

http : //twitter . com/login 

Si vous ne vous attendez pas a avoir beaucoup de pages de site, devrait vous 
aller (assurez-vous, malgre tout, de reserver « help »/« aide » et « about »/« a- 
propos »). 

Bien sur, si vous ne donnez pas les cles du magasin, vous n'avez aucun de ces 
problemes. Choisissez juste des URLs sensees pour les pages auxquelles les 
utilisateurs s'attendent. Et, bien entendu, assurez-vous de suivre tous les principes 
lies aux noms listes plus haut. 

C'etait facile, il ne nous reste done plus que les verbes. On peut imaginer pour les 
verbes deux fa^ons de fonctionner : 

on donne le nom au verbe : /share?v=1234 
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on donne le verbe ail nom : /v/1234?m=share 

Apres avoir passe beaucoup de temps a experimenter la-dessus, je suis convaincu 
que la deuxieme methode est la bonne. Elle prend moins de place dans « l'espace 
URL », c'est plus joli dans la barre d'adresse, et elle rend visuellement clair que 
l'on fait quelque chose a un objet. 

II est tentant d'utiliser des sous-pages, comme : 

/v/1234/share 

mais je prefere la formulation « ?m=share » pour deux raisons : d'abord, qa 
marche meme quand le nom a deja des sous-pages, et ensuite, qa rend clair que la 
page est censee faire quelque chose, et non simplement apporter plus 
d'informations. Mais la reciproque est vraie. Ne faites pas : 

/p/nancy_pelosi?m=finances 

qui donne l'impression que la page est supposee faire quelque chose alors qu'elle 
se contente en realite d'apporter plus d'informations. 

Tres bien, assez parle de choisir des URLs. Faisons maintenant quelque chose 
avec elles ! 
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Chapitre 3 

CONSTRUIRE POUR LES MOTEURS DE 
RECHERCHE : RESPECTER REST 



Parlons un peu d'aspirateurs. C'est une histoire des plus banales. Vous avez un joli 
appartement resplendissant, mais il ne reste pas comme qa longtemps. La 
poussiere tombe sur le sol, les miettes s'echappent de votre assiette, les debris, les 
epaves, et les petites pieces des figurines des Jetsons commencent a encombrer le 
chemin. II est temps de nettoyer. 

Balayer, c'est drole au debut - qa vous donne un peu de temps pour vous perdre 
dans vos pensees a propos de votre application web tout en vous livrant a une 
activite repetitive et ostensiblement utile - mais on s'en fatigue vite. Pourtant, une 
culpabilite de gauche et ces articles de Barbara Ehrenreich que vous avez lus vous 
font renacler a embaucher une femme de menage. Done au lieu d'importer d'un 
pays etranger une femme fauchee pour faire votre menage, vous embauchez un 
robot. 

Seulement, il y a cette chose avec les robots (et certaines femmes de menage, a ce 
point de vue) : la distinction n'est pas claire du tout pour eux entre ce qui est un 
dechet et ce qui a de la valeur. lis (les robots) se baladent dans la maison en 
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essayant d'aspirer des choses, mais sur leur chemin ils peuvent laisser des traces 
de roues sur votre manuscrit, renverser votre vase precieux, ou aspirer votre 
collection de pieces de monnaies antiques. Et parfois, il se prend dans le cordon 
des stores, et le robot tourne en rond tout en ouvrant sur les volets en tirant dessus. 

Alors vous prenez des precautions - avant de lancer le robot, vous relevez le 
cordon au-dessus du sol, posez votre manuscrit sur le bureau, et faites attention a 
ne pas laisser votre pile de pieces rares dans le coin. Vous vous assurez que 
l'endroit est pret pour que le robot puisse faire son travail sans causer de reel 
dommage. 

C'est exactement la meme chose sur le Web (a 1' exception de la poussiere, des 
miettes, des figurines Jetsons, des femmes de menage, des traces de roues, des 
vases, des pieces et des stores). Les robots (principalement ceux des moteurs de 
recherche, mais d'autres viennent des spammeurs, de lecteurs deconnectes, et de 
dieu sait quoi d' autre) parcourent toujours votre site, sans laisser un coin ou une 
fente inexplore, aspirant tout ce qu'ils peuvent trouver. Et contrairement a la 
variete electromenagere, vous ne pouvez pas vous contenter de les debrancher - 
vous devez absolument vous assurer de garder les choses propres®. 

Certaines personnes pensent qu'elles peuvent simplement bloquer les robots 
dehors. « Oh, il faut s'identifier pour entrer ; va retenir les robots ». C'est ce que 
disait David Heinemeier-Hansson, le createur de Rails. II se trompait. Les logiciels 
de Google qui tournaient sur les ordinateurs des usagers ont fini par explorer 
meme les pages qui necessitaient une identification, ce qui signifie que les robots 
ont clique sur tous les liens « Supprimer », ce qui signifie que les robots ont efface 
tout le contenu (Hansson, pour sa part, a repondu en pleurnichant contre 1' injustice 
de tout ^a). Ne laissez pas cela vous arriver. 

Par chance, ce genial Tim Berners-Lee (voir le chapitre precedent) avait anticipe 
cela et pris des precautions. Vous voyez, quand vous visitez un site web, vous ne 
demandez pas seulement PURL au serveur, vous lui dites aussi quel type de 
requete vous faites. Voici une requete HTTP/1.0 typique : 

8 Voir http://ftrain.com/robot_exclusion_protocol.html. 
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GET/about/HTTP/1.0 

La premiere partie (« GET ») s'appelle la methode, la deuxieme (« /about/ ») est le 
chemin, et la troisieme (« HTTP/1.0 ») est evidemment la version. GET est la 
methode avec laquelle nous sommes sans doute tous familiers -c'est la methode 
normale qu'on utilise pour obtenir (to get, en anglais) une page. Mais il y a aussi 
une autre methode : POST. 

Si vous pensez les URLs comme des petits programmes installes quelque part dans 
un serveur, on peut considerer que GET fait juste tourner le programme et recupere 
une copie de ce qu'il en sort, alors que POST lui envoie plutot un message. En fait, 
a la difference des requetes GET, les requetes POST viennent avec un chargement. 
Un message est accroche dessus, pour que l'URL en fasse ce qu'elle veut. 

Ca sert pour les requetes qui font quelque chose qui bouleverse l'ordre de 
l'univers (ou, dans le jargon, qui « changent l'etat »), au lieu de simplement 
essayer de comprendre qu'est-ce qui est quoi. Ainsi, par exemple, lire une vieille 
histoire est un GET, puisque vous essayez simplement de comprendre des trues, 
mais aj outer un article a votre blog est un POST, puisque vous changer reellement 
l'etat de votre blog. 

(Maintenant, si vous voulez jouer au con, vous pouvez dire que toutes les requetes 
bouleversent l'ordre de l'univers. Chaque fois que vous demandez une vieille 
histoire, qa utilise de l'electricite, qa deplace des tetes sur des disques durs, qa 
ajoute une ligne sur le journal du serveur, qa met une note dans votre dossier a la 
NSA, etc. C'est absolument vrai, mais il semble bien que qa n'a rien a voir avec ce 
dont on parle, alors n'en parlons plus. Pardon, la NSA ?) 

Le resultat final est tres clair. Ca va si Google parcourt et lit de vieilles histoires, 
mais qa ne va pas s'il vient poster sur votre blog (ou pire, y effacer des choses). Ce 
qui implique que lire des histoires doit etre du GET, et effacer des articles de blog 
du POST. 

En realite, ga n'est pas tout a fait vrai. II y a d'autres verbes au cote de GET et 
POST (bien que ceux-ci soient, de loin, les plus courants). II y a GET, HEAD, 
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POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, 
PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE (et 
probablement d'autres encore). GET et POST, nous les avons deja vus. HEAD est 
comme GET, mais ne reclame que Pen-tete de la page et pas son veritable 
contenu. PUT est la si vous voulez changer le contenu de la page par quelque 
chose d'entierement nouveau - le navigateur web originel de Tim Berners-Lee 
utilisait PUT quand vous tentiez de sauvegarder un changement fait sur la page. 
PATCH est comme PUT, mais ne change qu'une partie de la page. DELETE 
(supprimer), MOVE (deplacer), COPY (copier), LOCK (verrouiller), et 
UNLOCK (deverrouiller) s'expliquent plutot bien d'eux-memes. CONNECT 
s'utilise pour proxyfier et « tunneler » d'autres choses. OPTIONS vous laisse 
decouvrir ce que tolere le serveur. PROPFIND et PROPPATCH sont utilises pour 
regler les proprietes dans le protocole WebDAV. MKCOL sert a faire des 
collections WebDAV (ces derniers n'auraient sans doute pas du avoir leurs propres 
methodes). TRACE demande au serveur de simplement repeter la requete qu'il a 
recue (c'est utile pour le debogage). 

Mais bon, franchement, GET et POST sont les plus frequents, en grande partie 
parce que ce sont ceux supportes par tous les navigateurs web. GET, bien sur, et 
utilise a chaque f ois que vous saisissez une URL ou cliquez sur un lien, tandis que 
POST peut etre utilise dans certains formulaires (les autres formulaires sont en 
GET, done qa ne change rien). 

Suivre ces regies, c'est respecter REST, d'apres la these de doctorat de 2000 de 
Roy Fielding, coauteur (avec Tim Berners-Lee et quelques autres) des 
specifications officielles du HTTP (RFC 2616, si qa vous interesse). Roy, une sorte 
d'ours avec un penchant pour le sport, s'est propose de decrire theoriquement les 
divers styles (« architectures ») d' applications basees sur le reseau. Puis il a decrit 
l'hybride interessant que le Web a adopte, qu'il appelle « transfert d'etat 
representationnel » (Representational State Transfer) ou REST. 

Bien que REST soit souvent evoque pour dire quelque chose comme « utiliser 
GET et POST correctement », c'est en realite bien plus complexe et interessant 
que qa, et nous allons passer un peu de temps dessus pour que vous puissiez voir 
les differentes sortes de compromis architecturaux auxquels ont du penser ces 
maitres de l'univers qui ont con^u un systeme comme le Web. 
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Le premier choix fut que le Web serait un systeme client-serveur. Honnetement, le 
Web est probablement comme qa parce que Tim a fait les choses comme qa, et Tim 
a fait les choses comme qa parce que c'est comme qa que toutes les choses sur 
Internet etaient a l'epoque. Mais il n'est pas impossible d'imaginer que le Web 
aurait pu etre plus pair-a-pair, comme certains services d'echange de fichiers 
qu'on voit aujourd'hui (apres tout, le Web est en grande part du simple echange de 
fichiers). 

L' option la plus facile serait, bien sur, de rompre avec le Web dans son ensemble, 
et de forcer les gens a telecharger un logiciel particulier pour utiliser votre 
application. Apres tout, c'est comme qa que fonctionnaient la plupart des 
applications avant le Web (et que fonctionnent encore beaucoup aujourd'hui) - 
nouveau logiciel, nouveaux protocoles, nouvelle architecture pour chaque 
application. II y a certainement de bonnes raisons de faire cela, mais ^a vous coupe 
du reste de la communaute du Web - on ne peut pas faire de lien vers vous, vous 
ne pouvez pas etre parcouru par Google, vous ne pouvez pas etre traduit par 
Babelfish, etc. Si c'etait un choix que vous souhaitiez faire, vous ne seriez 
probablement pas en train de lire ce livre. 

Le deuxieme choix majeur fut que le web serait « sans etat ». Imaginez une 
connexion reseau ou votre ordinateur appellerait le QG et commencerait une 
conversation. Dans un protocole avec etats, il y a de longues conversations - 
« Alio ? » « Alio, bienvenue sur Amazon. Je suis Shirley. » « Bonjour Shirley, 
comment-allez-vous ? » « Oh, tres bien, et vous ? » « Oh, bien, tres tres bien. » 
« J'en suis ravie. Que puis-je faire pour vous ? » « Eh bien, je me demandais ce 
que vous aviez dans votre rayon litterature. » « Hmm, laissez-moi voir. Ah, il 
semble que nous ayons plus de 15 millions de livres. Pourriez-vous etre un peu 
plus precis ? » « Oui, est-ce que vous en avez de Dostoi'evski ? » (etc.). Mais le 
Web est sans etat - chaque connexion commence a zero, sans anteriorite. 

Ca a ses bons cotes. Par exemple, si vous etes en pleine recherche d'un livre sur 
Amazon quand, juste au moment ou vous etes sur le point de le trouver vous 
regardez l'heure et saperlipopette ! il est tard, vous allez manquer votre avion ! 
Alors vous claquez votre ordinateur portable, vous le fourrez dans votre sac, vous 
vous ruez vers la porte, vous embarquez dans 1' avion, et finalement, vous arrivez a 
l'hotel apres une journee entiere, et rien ne vous empeche de rouvrir votre portable 
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dans ce pays completement different et de reprendre votre recherche la ou vous en 
etiez reste. Tous les liens fonctionnent toujours, apres tout. Une conversation avec 
etat, en revanche, ne survivrait certainement pas a une pause d'un jour ou a un 
changement de pays (de la meme maniere, vous pouvez envoyer un lien vers votre 
recherche a un ami de 1' autre cote du monde et vous deux pourrez l'utiliser sans 
probleme). 

C'est benefique pour le serveur egalement. Au lieu d' avoir chaque client accroche 
a une partie d'un serveur en particulier pour aussi longtemps que durera la 
conversation, les conversations sans etat sont expedites tres rapidement, et 
peuvent etre tenues par n'importe quel vieux serveur, etant donne qu'ils n'ont pas 
besoin de connaitre un historique. 

Certaines mauvaises applications web essayent de s'affranchir de la nature sans 
etat du Web. La fa^on la plus courante de le faire est l'utilisation de cookies de 
session. Maintenant, il y a assurement de bonnes raisons d'utiliser des cookies. 
Exactement comme quand vous appelez votre banque et qu'ils vous demandent 
votre numero de compte pour pouvoir retrouver votre dossier, les cookies peuvent 
permettre aux serveurs de construire des pages arrangees sur-mesure pour vous. II 
n'y a rien de mal avec ga. 

(Cependant on pourrait se demander si les utilisateurs ne gagneraient pas a utiliser 
la methode d'authentification Digest, plus sure et construite en HTTP, mais 
comme a peu pres toutes les applications sur le Web utilisent aujourd'hui des 
cookies, c'est sans doute une cause perdue. II y a quelques espoirs d' amelioration 
en HTML5 (la prochaine version d'HTML) puisqu'ils - oh, attendez, ils ne vont 
pas s'occuper de ^a. Hmm, bon, je vais tenter de le leur suggerer.)^ 

Le vrai probleme apparait quand on utilise les cookies pour creer des sessions. Par 
exemple, imaginez si Amazon.com n'avait qu'une URL : 
http://www.amazon.com/. La premiere fois que vous visiteriez le site, il vous 
donnerait la page d'accueil et un numero de session (disons 349382). Ensuite, 
vous enverriez un rappel en disant « Je suis la session numero 349382 et je veux 

9 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016742.html. 
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chercher des livres », et il vous renverrait en retour la page des livres. Puis vous 
renverriez un rappel en disant « Je suis la session numero 349382 et je veux 
chercher Dostoievski ». Et ainsi de suite. 

Aussi fou que cela puisse paraTtre, beaucoup de sites fonctionnent de cette fa^on 
(et encore plus Font fait par le passe). Pendant des annees, le plus coupable rut 
probablement la boite a outils appelee WebObjects, celebre particulierement pour 
avoir pilote le magasin en ligne d'Apple. Mais, apres des annees et des annees, il 
semblerait que WebObjects ait ete repare. Pourtant, de nouvelles plateformes 
comme Arc et Seaside surgissent pour prendre sa place. Toutes font ^a pour la 
meme raison basique : ce sont des logiciels pour construire des applications web 
qui veulent garder le Web hors de votre vue. lis veulent faire ^a pour que puissiez 
ecrire un logiciel normalement, et qu'il devienne magiquement une application 
web, sans que vous ayez a fournir le travail de penser les URLs ou de respecter 
REST. Eh bien, vous pouvez obtenir a partir de ^a une application utilisable avec 
un navigateur, mais vous n'obtiendrez pas une application web. 

Le morceau suivant de l'architecture du Web est la memoire cache. Puisque nous 
avons cette longue serie de requetes sans etat, ^a serait surement bien si on pouvait 
les garder en cache. Est-ce que ^a ne serait pas formidable si chaque fois que Ton 
presse le bouton retour, le navigateur n'avait pas besoin de retourner au serveur et 
de recharger toute la page ? Si, bien sur. C'est pourquoi tous les navigateurs 
enregistrent les pages en cache - ils en garde une copie en local et se contentent de 
vous la presenter si vous en refaites la requete. 

Mais il n'y a pas de raison de se limiter au cache des navigateurs. Les FAI aussi 
utilisent parfois la memoire cache. Ainsi, si une personne telecharge la bande- 
annonce du dernier gros film, le FAI peut en garder une copie, et servir le meme 
fichier a tous leurs clients. Qa rend les choses bien plus rapides pour les clients 
(qui ne sont pas en competition avec le monde entier pour les memes fichiers) et 
bien plus faciles pour l'operateur du serveur (qui n'a plus besoin de fournir autant 
de copies). Le seul probleme est que qa a tendance a perturber un peu vos 
statistiques de telechargement, mais les operateurs de serveurs peuvent decider si 
le jeu en vaut la chandelle. 
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De la meme fa^on, les serveurs peuvent utiliser la memoire cache. Plutot que les 
navigateurs visitent directement le serveur, ils tombent sur un serveur cache 
(appele techniquement un reverse proxy, ou proxy inverse) qui verifie s'il ne 
possede pas deja une copie de la page et qui, s'il 1' a, la fournit, et sinon la reclame 
au veritable serveur. Si vous construisez votre application web en respectant 
REST, vous pouvez souvent rendre votre site beaucoup, beaucoup plus rapide en 
collant simplement un chouette serveur cache (comme Polipo) devant lui. Mais, 
evidemment, si vous faites mal les choses en utilisant par exemple des cookies de 
sessions et en ignorant les regies de GET et POST, le serveur cache va juste tout 
bousiller (notez que seules les requetes GET peuvent etre sauvees en cache ; vous 
ne voudriez pas mettre en cache le resultat de quelque chose comme aj outer un 
nouvel article de blog, sinon l'article suivant ne serait jamais ajoute !). 

GET et POST sont, bien sur, une partie du morceau suivant de 1' architecture que 
Fielding appelle « interfaces uniformes ». Toutes les applications web 
fonctionnent de la meme maniere : elles sont une serie d'URLs sur lesquelles vous 
appliquez des methodes. Les methodes changent parfois l'etat de l'objet, et le 
serveur renvoie toujours la « representation » de l'objet qui en resulte. 

D'ou son nom : transfert d'etat representational, Representational State Transfer, 
REST. 
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CONSTRUIRE POUR LE CHOIX : AUTORISER 
IMPORTATION ET EXPORTATION 



Les robots, les navigateurs et les protocoles sont sympas, c'est sur, mais si vous 
voulez que votre site ait du succes, il faut qu'il plaise aux humains - les vrais gens 
qui construisent et utilisent tous ces autres trues. Et meme si qa n'est pas le cas de 
rinformation, les humains veulent habituellement etre libres. Si vous ne me 
croyez pas, demandez a un ami de vous enfermer dans son coffre de voiture, puis 
reevaluez votre position. 

Les gens cupides (i.e les hommes d'affaires) ont tendance a ne pas voir plus loin 
que le bout de leur nez dans ce domaine. « Si je mets des grosses pointes de metal 
devant la sortie », pensent-ils, « mes clients ne voudront jamais partir ! Mon taux 
de retention de clientele va monter en fleche ». lis decident d'essayer, et font 
installer quelques grosses pointes de metal devant la sortie. Et, comme les 
hommes d'affaires aiment pretendre qu'ils sont des personnes realistes et sensees, 
ils mesurent les taux de retention de clientele avant et apres 1' installation des 
pointes de metal. Et, bien evidemment, qa a fonctionne - les gens ne partent pas. 
Jetez juste un ceil a ces chiffres ! Mais ce qu'ils ne mesurent pas, c'est que les gens 
ne reviennent pas non plus. Apres tout, personne ne veut aller quelque part ou il y 
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a des pointes a la sortie. Pensez-y la prochaine fois que vous trouvez que les pubs 
en pop-up augmentent le taux de rotation du stock. 

C'est pourquoi un site comme Amazon est un tel fouillis d'encarts de vente. Les 
gestionnaires d' Amazon insistent sur le fait qu'ils sont des ingenieurs 
rigoureusement realistes. Les encarts sont la parce qu'ils vendent des choses et 
leur role est de rapporter de l'argent. Les pages propres, claires, sans desordre 
plaisent peut-etre aux gamins en ecole d'art ou aux stagiaires de chez Apple, mais 
ici dans le monde reel, l'argent fait loi. Et, a l'instar de Mark Penn conseillant 
Hillary Clinton, si vous ne les croyez pas, ils sortent les chiffres pour le 
« prouver ». Chaque encart, disent-ils, a ete soigneusement teste : on a donne a la 
moitie des utilisateurs une page avec le nouvel encart, et a 1' autre moitie une page 
sans. Et les utilisateurs a qui on a donne la page avec l'encart ont plus achete. 

Oui, sans doute. Manifestement, il y a plus de gens qui vont acheter quelque chose 
si on leur propose, tout comme plus de clients de McDonald vont choisir le grand 
menu quand 1' adolescent bougon va le leur proposer. Mais Amazon va plus loin 
que qa - la, on est dans le royaume de la fille-au-micro-casque qui nous relance 
tous les trois articles du menu. C'est sur, on va acheter plus cette fois, mais apres 
l'indigestion on se promettra que la prochaine sortie se fera au Burger King. 

Les entreprises essayent rarement de mesurer ce genre d'effets et meme quand 
elles le font, qa n'est pas facile. C'est enfantin de donner a quelqu'un un lien 
additionnel, et de regarder s'il clique dessus ; garder trace de leur eventuel retour 
au magasin dans les semaines ou les mois a venir est bien plus difficile. Pire 
encore, la difference faites par un encart en plus est subtile, et done compliquee a 
mesurer. Le vrai test n'est pas de verifier si Amazon attire plus de clients en 
retirant un encart, mais plutot en optant pour une apparence plus douce et 
agreable. Mais qa serait un changement radical pour Amazon - et done tres 
difficile a tester sans en herisser ou effrayer certains. « Eh bien, si on ne peut pas 
mesurer les gens », disent les MBAs, « on peut au moins leur demander ». D'ou 
les redoutables « focus groups », dont les defauts peuvent eclipser meme la plus 
fausse des etudes statistiques. Au moins, en jouant avec les clics, vous mesurer ce 
que les gens font vraiment ; avec les focus groups vous decouvrez ce que les gens 
veulent que vous pensiez qu'ils disent qu'ils font, ce qui est tres different. 
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Deja, les gens sont notoirement de mauvais observateurs d'eux-memes. Pour la 
plupart, on ne sait pas pourquoi ni comment on fait les choses, done quand on 
nous demande on improvise sur le coup une rationalisation fabrique. Ca n'est pas 
du manque d' attention - c'est comme qa que le cerveau fonctionne. Pour 
accomplir des taches de quelque complexite que ce soit, on a besoin de rendre 
automatiques les parties qui les composent - on n'atteindrait jamais le magasin si 
on avait a reflechir a quel muscle de la cuisse bouger pour mettre la jambe dans la 
bonne position - et les comportements automatiques sont exactement des 
comportements auxquels on ne pense pas (c'est pour ^a que les autobiographies de 
sportifs sont si ennuyeuses (10) ). 

Ainsi, non seulement vous posez une question a des gens a laquelle ils ne savent 
pas - et ne peuvent pas savoir - repondre, mais en plus vous leur demandez qa 
dans une belle salle de reunion, remplie d'autres personnes, apres leur avoir donne 
des sous. II n'est pas necessaire de lire beaucoup en psychologie sociale pour 
comprendre que qa n'est pas exactement une situation ideale pour l'honnetete. Les 
gens vont, evidemment, dire ce qu'ils pensent que vous souhaitez entendre, et 
meme si vous faites poser les questions par le plus neutre des moderateurs, ils 
seront en mesure d'emettre une supposition eclairee sur ce que ^a doit etre. 

C'est pour cela que regarder des groupes de travail est une experience si 
exasperante : comme une fille qui fait semblant de jouer l'idiote dans un bar, vous 
observez des gens se comporter de la fa^on qu'ils croient etre ce qu'on attend des 
gens comme eux. 

Mais si on ne peut ni mesurer les gens ni les interroger, que nous reste-t-il ? Eh 
bien, la bonne experience a l'ancienne. Comme c'est souvent le cas dans la vie, il 
n'y a pas de raccourcis autour de 1' incompetence ; a un moment, vous avez besoin 
de reelles aptitudes. Quant il s'agit de satisfaire les utilisateurs, il y a generalement 
deux parties : d'abord, il vous faut une dose de base d'empathie, la capacite a vous 
mettre a la place de l'utilisateur, et de voir les choses avec ses yeux. Mais pour que 
qa fonctionne, vous avez aussi besoin de savoir ce qu'il y a a l'interieur de la tete 
de l'utilisateur, et d'apres moi, la meilleure fa^on d'y arriver est simplement de 
passer beaucoup de temps avec eux. 

10 Voir D. F. Wallace, « How Tracy Austin Broke My Heart » in Consider the Lobster (2005) [non- 
traduit en francais]. 
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Le meilleur expert en utilisabilite du monde, Matthew Paul Thomas, a commence 
en travaillant quelques annees en tant que support technique dans un cybercafe de 
Nouvelle-Zelande. C'est le genre de travail vers lequel on imaginerait Staline 
exiler des programmeurs, mais Thomas en a tire le meilleur. Au lieu de devenir 
aigri a l'encontre des utilisateurs stupides qui ne comprennent pas ce qu'est une 
« barre des taches », il en a eu ras-le-bol des idiots qui con^oivent des systemes 
necessitant ce genre de connaissances esoteriques. Et maintenant qu'il est en 
position de regler ce genre de problemes, il comprend ces defauts de maniere plus 
viscerale. 

Je ne souhaite ce genre d'exil force a personne (meme si je suppose que quelques 
concepteurs d'interfaces feraient de bons candidats), mais il n'y a certainement 
pas penurie de gens qui possedent deja, a divers degres, cette intuition de 
l'utilisateur. Le probleme, c'est que personne ne les ecoute. II est toujours 
tellement facile de les taxer de naivete, de stupidite ou de ringardise. Apres tout, 
cette option de barre de menu additionnelle que vous souhaitez aj outer est 
parfaitement claire a vos yeux - quel mal pourrait-elle vraiment faire ? 

Quand une entreprise se focalise sur ses usagers, c'est un vrai choc. Prenez 
Zappos, un magasin de chaussures en ligne. Chez Zappos, ce sont des fanatiques 
du service aux clients. lis surclassent discretement les primo-acheteurs en 
livraison « demain chez vous », ils ecrivent des cartes et envoient des fleurs quand 
la situation le justifie, et ils ne se contentent pas de rembourser totalement les 
retours, mais payent aussi pour la reexpedition. C'est le genre d' entreprise que les 
gens couvrent d'eloges. Mais, et c'est plus interessant encore pour notre sujet, s'ils 
n'ont pas en stock les chaussures que vous voulez, ils essayent de trouver un 
concurrent qui les a ! 

D'une perspective a court terme, parait absurde : pourquoi voudriez-vous 
travailler pour aider vos clients a acheter des chaussures chez quelqu'un d'autre ? 
Mais a long terme, c'est du genie. Bien sur, vous ferez peut-etre un achat quelque 
part ailleurs, mais non seulement vous reviendrez chez Zappos pour chaque achat 
de chaussures jusqu'a la fin de vos jours, mais vous allez aussi ecrire des articles 
de blog longs et embrases sur le fait que Zappo est incroyablement super. 
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C'est Tun des secrets du succes sur le Web : plus vous envoyez de gens ailleurs, 
plus ils reviennent. Le Web est plein de « noeuds feuilles » - des pages qui disent 
quelque chose d'interessant, mais qui ne vous renvoient pas vraiment plus loin. Et 
les noeuds feuilles sont tres bien - ils sont le coeur du Web, en fait - mais ce sont 
des fins de voyages, pas des commencements. Quand quelqu'un debute sa 
journee, ou demarre son navigateur, il veut une page qui l'emmene vers tout un 
bouquet de sites et de perspectives, pas qui essaye juste de le garder enferme a un 
endroit. Quel est le site le plus populaire sur Internet, et de loin ? Google Search, 
un site dont le but est de vous envoyer ailleurs le plus rapidement et le plus 
discretement possible. 

La raison pour laquelle tous ces trues a propos de pointes de metal, d'exil en 
Nouvelle-Zelande, de magasin de chaussures et de noeuds feuilles sont pertinents 
dans un livre sur les applications web est que je vais maintenant vous demander de 
faire quelque chose qui a Fair insense, quelque chose dont on dirait que pourrait 
tuer votre site. Je vais vous demander d'ouvrir vos donnees. Abandonnez-les. 

Je vous laisse une seconde pour reprendre votre respiration. 

Ca n'est pas aussi fou que cela parait. Wikipedia, un site a succes quel que soit la 
facon de le mesurer, laisse les cles du magasin - vous pouvez telecharger l'integralite 
des bases de donnees a un instant T, ce qui inclue en plus de chaque page de 
Wikipedia chaque changement fait sur chaque page, le tout avec la pleine autorisation 
de republier ca comme il vous plaira. Ca n'a pas Fair de nuire a sa popularite. 

Bien evidemment, je ne suis pas en train de vous dire de publier a tous les vents les 
details personnels de vos utilisateurs. II serait fou de la part de Gmail de proposer 
un site ou on pourrait telecharger chacun des mails de leurs utilisateurs. A la place, 
je vous suggere de permettre a vos utilisateurs de recuperer leurs propres donnees 
depuis votre site. Les gens qui importent leurs evenements sur votre calendrier 
devraient pouvoir exporter leur calendrier ; les gens qui re^oivent leurs mails via 
Gmail devraient pouvoir les recuperer ensuite. 

Permettre une bonne exportation n'est pas simplement la chose a faire parce que 
c'est juste, peut egalement etre une fa^on efficace d'attirer des utilisateurs. Les 
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gens ne sont pas a l'aise avec l'idee de verser toute leur vie dans une application 
web hebergee - ils se sont trop faits avoir trop de fois par des entreprises qui leur 
ont pris toutes leurs donnees puis on fait faillite. Vous donner du mal pour vous 
assurer qu'ils puissent recuperer leurs affaires depuis votre site est un bon moyen 
de regagner leur confiance. 

Bien que j'aie beaucoup de choses a dire sur les formats dans ce livre, la question 
du format que vous utiliserez ici n'est pas vraiment pertinente. Ce qui est 
important, c'est que vous le fassiez. XML, RDF, CSV - le systeme de blogs 
populaire Movable Type exporte simplement les articles sous forme de longs 
fichiers texte, et etant donne le format affreux qu'ils utilisent, c'est mieux que rien. 
A partir du moment ou vous choisissez quelque chose d'a moitie sense, les gens 
trouveront un moyen pour que qa marche. 

L' exception c'est quand il y a deja un standard dans votre domaine (de facto, ou 
pour une autre raison). Par exemple, OPML est tres largement accepte comme la 
fa^on d'exporter la liste de blogs que vous lisez. Si c'est le cas, vous devez utilisez 
ce standard. Desole. Si un autre logiciel fournit dans une mesure trop importante 
un certain format, vous devrez juste avaler la pilule et fournir une exportation dans 
ce format. Tout le reste semblerait grassier, et les utilisateurs ne vont pas 
s'interesser aux details techniques. 

Et, bien sur, qa va dans les deux sens : un bon moyen d'attirer les utilisateurs est de 
fournir une fonctionnalite d'importation vous-meme. En permettant l'importation 
depuis d'autres produits, qu'ils aient des fonctionnalites d'exportation officielles 
ou non, vous rendez plus facile pour les utilisateurs la migration vers votre propre 
version. Meme si vos concurrents n'ont pas de fonction d'exportation officielle, 
vous pouvez toujours aider les utilisateurs a sortir (et offenser vos concurrents) en 
grattant les donnees de leur systeme - en ecrivant des outils maison pour recuperer 
les trues depuis leur interface utilisateur et les verser dans votre base de donnees. 

De tout qa resulterait le genre de monde sans friction dont les utilisateurs futes 
doivent rever - glisser en douceur d'une application a 1' autre, benef icier des 
avantages d'une nouvelle fonctionnalite sans devoir abandonner ses anciennes 
donnees. Et si l'entreprise qui faisait ga se fait racheter, et que les developpeurs qui 
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ont ecrit toutes ces nouvelles fonctionnalites s'en vont et lancent un concurrent, 
vous pouvez recuperer vos donnees aussitot et sauter sur la nouvelle application. 

Ce qui signifie plus de choix - et n'est-ce pas ce qu'il y a de mieux pour tout le 
monde ? 
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CONSTRUIRE UNE PLATEFORME : FCXJRNIR 
DES APIS 



L' autre semaine j'ai fait une de mes rares excursions hors de mon lit 
somptueusement attitre, et je me suis rendu a une fete locale. J'y ai rencontre un 
homme qui avait realise un site web pour charger et visualiser des donnees. Je 
lui ai demande s'il avait une API, puisque cela semble vraiment utile pour un 
site tellement oriente vers les donnees. II n'en avait pas, m'a-t-il dit ; 
demanderait trop de travail de maintenir a la f ois une application normale et une 
API. 

Je vous raconte cette histoire parce que ce type de la fete avait tort, mais 
probablement de la meme fa^on que vous avez tort, et je ne veux pas que vous 
vous sentiez mal. Si meme un jeune fondateur de start-up bien habille dans un 
salon chic de Williamsburg commet cette erreur, n'est pas un grave peche. 

En fait, 1' erreur est que si vous construisez votre site web en suivant les principes 
exprimes dans ce livre, l'API n'est pas quelque chose de distinct de votre site 
normal, mais en est une extension naturelle. Tous les principes que nous avons 
evoques - URLs intelligentes, GET et POST, etc. - s'appliquent aussi bien aux 
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sites web qu'aux APIs. La seule difference est qu'au lieu de renvoyer du HTML, 
vous voulez renvoyer du JSON a la place. 

JSON (qu'on prononce « Jason »), pour les non-inities, est un simple format pour 
echanger de bouts de donnees basiques entre logiciels. Base originellement sur 
JavaScript, mais rapidement adopte par presque tous les langages principaux, il 
rend le partage de donnees sur le Web facile. 

« Attendez ! », criez-vous peut-etre, « je pensais que le XML servait a echanger 
des donnees sur le Web ». Malheureusement, vous avez ete induit en erreur par 
une sinistre et nefaste campagne de relations publiques. XML est probablement 
quelque chose comme le pire format pour echanger des donnees. Voila pourquoi : 

Les langages modernes de programmation ont largement etabli des standards 
concernant les memes composants de structure interne des donnees : entiers, 
chaines, listes, sommes de controle, etc. JSON les reconnait et rend facile le 
partage de ces structures de donnees. Vous voulez partager le nombre 5 ? Ecrivez 
simplement 5. La chaine « foo » est simplement "foo". Une liste des deux est 
simplement « [5, "foo"] » - et ainsi de suite. 

C'est facile a ecrire et a lire pour les humains, mais surtout, et c'est encore plus 
important, c'est automatique a ecrire et a lire pour les ordinateurs. Dans la plupart 
des langages vous n'avez meme pas besoin de penser au fait que vous utilisez 
JSON : vous demandez simplement a votre bibliotheque JSON de serialiser une 
liste, et elle le fait. Vous lisez un fichier JSON, et pour votre programme c'est juste 
une structure normale de donnees. 

XML, de son cote, ne supporte rien de tout ^a. A la place, il pense en termes 
d' elements avec des donnees textuelles, des instructions de programmation et des 
attributs, qui sont tous des chaines. Publier des donnees en XML necessite de 
comprendre comment faire rentier au chausse-pied vos donnees internes dans un 
format specif ique, puis de vous assurer que vous l'avez decode correctement. 
Encoder du XML est encore pire. 

La raison principale pour laquelle XML est si mauvais pour echanger des donnees 
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est qu'il n'a pas ete congu pour qa en premier lieu. C'etait un format pour baliser 
des documents textuels ; ecrire des annotations avec des instructions de formatage 
de diverses sortes, a la maniere d'HTML. C'est pour qa qu'il fait la distinction 
entre donnees textuelles et donnees d'attribut - les donnees d'attributs sont des 
choses qui ne font pas partie du texte veritable, comme : 

J ' attends avec impatience une demonstration <font 
color="green">couronnee de succes</font> . 

Le mot « green » est une annotation, pas une partie du texte, done va dans un 
attribut. Tout qa passe par la fenetre quand vous commencez a parler de 
donnees : 

<personne age="5"> 
<nom>Robert Booker</nom> 
</personne> 

Pourquoi « age » est un attribut, alors que « nom » est un element ? C'est 
completement arbitraire, parce que la distinction est absurde. 

D'accord, done XML a quelques fonctionnalites en plus dont personne n'a besoin. 
Quel mal a qa ? Eh bien, il manque aussi tout un paquet de fonctionnalites dont 
vous avez besoin - par defaut, XML ne supporte pas le concept on ne peut plus 
basique qu'est le nombre entier ; il n'y a que des chames. Et a cela s'ajoute le fait 
qu'il requiert d'utiliser le Schema XML, une specification tellement affligeante de 
complexite qu'elle verrouille mon navigateur quand j'essaye de l'ouvrir. 

Mais le cout d'une telle complexite n'est pas simplement plus de travail pour le 
developpeur - il se ressent veritablement sous la forme de bugs, particulierement 
des failles de securite. Comme 1' observe 1' expert en securite Dan Bernstein, deux 
des principales sources de failles de securite sont la complexite (« Les failles de 
securite ne peuvent pas apparaitre dans des fonctionnalites qui n' existent pas ») et 
l'encodage (« L'encodage est souvent source de bugs... Le decodage est souvent 
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source de bugs... Rares sont les occasions heureuses ou l'encodage et le decodage 
font la meme mauvaise interpretation de l'interface 

XML combine le pire des deux mondes : c'est un systeme incroyablement 
complexe a encoder. Sans surprise, XML a ete responsable de centaines de failles 
de securite.t 12 ) 

A part le fait d'etre plus simple, plus facile d'utilisation, plus sur et plus rapide 
qu'XML, qu'est-ce que JSON a a offrir ? Eh bien, il a une fonctionnalite qui 
dechire qui lui a assure cette victoire dans la guerre des formats : parce qu'il est 
base sur JavaScript, il a une profonde compatibilite avec les navigateurs web. 

Vous avez probablement entendu parler d'AJAX, une technique qui utilise la 
fonction XmlHttpRequest dans les navigateurs web modernes pour permettre aux 
pages de lancer leurs propres requetes HTTP pour recevoir plus de donnees. Mais 
pour des raisons de securite, XmlHttpRequest n'autorise que des requetes sur le 
meme domaine que la page web d'ou elles sont lancees. C'est a dire que si votre 
page est a l'adresse http://www.exemple.net/foo.html elle peut demander des 
choses comme http://www.exemple.net/info.xml, mais pas 
http://whitehouse.gov/data/dump.xml. 

Pour les APIs, c'est une veritable catastrophe - tout l'enjeu de l'ouverture des 
donnees sur le Web reside dans le fait que les autres sites puissent les utiliser. Si 
vous etes la seule personne qui puisse y acceder, pourquoi s'en dormer la peine ? 

Heureusement, il existe une exception : JavaScript. Une page web peut integrer 
une balise HTML « <script> » qui pointe sur n'importe quel site sur Internet. II y a 
meme mieux : le code JavaScript peut ajouter arbitrairement ces balises script a la 
page. Le navigateur part alors chercher la page, et essaye de l'executer. 

Maintenant, avec du JSON basique, ne serait pas tres utile - la navigateur 
telechargerait une liste, un objet, ou quelque chose, et ne saurait pas quoi en faire. 

11 Voir http://cr.yp.to/qmail/guarantee.html. 

12 Voir http://eve.mitre.org/. 
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Done aii lieu de simplement renvoyer du JSON, renvoie du JSON emballe dans 
un appel de fonction : 

myCallback( [5, "foo"]); 

Et vous n'avez plus qu'a faire faire a la fonction « myCallback » ce que vous 
voulez qu'elle fasse avec les donnees. 

Evidemment, si vous faites beaucoup de requetes, vous voulez les maintenir 
separees - elles ne peuvent pas toutes appeler myCallback. Alors vous supportez 
un parametre de rappel qui vous permet de choisir le nom de la fonction. Ainsi, 
une URL comme http://www.exemple.net/info.json?callback=foo renverra : 

foo([5, "foo"]); 

La technique complete est connue sous le nom de JSONP et, naturellement, elle 
est automatisee par toutes les principales bibliotheques JSON, done vous n'avez 
pas a vous embeter avec ces details. 

Tres bien, done maintenant nous disposons d'une pile de JSON, ou est-ce qu'on la 
met. La reponse, bien sur, est « a la meme place que votre HTML ». Revenons a 
un exemple ancien, disons que nous avons des informations a propos d'un livre a 
l'adresse : 

http : //livres . exemple . org/b/3j 7is 
Ou va le JSON ? Exactement au meme endroit ! 

En fait, HTTP a une chouette fonctionnalite appelee Content Negotiation, 
negociation de contenu, qui permet a la meme URL de renvoyer des formats 
differents selon l'emetteur de la requete. L' exemple classique de negociation de 
contenu est la transition depuis les images GIF vers le format d' images plus recent 
PNG. Certaines vieilles versions dTnternet Explorer ne supportaient pas le PNG ; 
les serveurs pouvaient utiliser la negociation de contenu pour leur envoyer les 
vieilles images GIF a la place. 
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La fa^on dont ^a fonctionne est qu'a chaque fois que faites une requete HTTP 
(comme un GET), le client envoie en meme temps une serie d'en-tetes Accept, qui 
disent quels formats il aime. Voici un exemple typique : 

Accept: text/html; q=1.0, text/*; q=0.8, image/gif ; 
q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 

Ca dit que le navigateur prefere le HTML, puis prend le texte, puis les GIFs et les 
JPEGs, puis toutes les autres images, puis tout le reste. 

Mais pour les APIs, nous n'avons pas besoin de faire quelque chose d'aussi 
complique. On peut simplement demander aux clients de notre API d'envoyer : 

Accept: application/j son 

et faire en sorte que le serveur ouvre l'oeil la-dessus, et renvoie la version JSON 
s'il le voit. Dans le cas contraire, il renvoie la version HTML comme d'habitude. 

Bien sur, vous souhaiterez probablement proposer une option pour les gens qui ne 
ne sont pas a l'aise avec la negotiation de contenu. Traditionnellement, on fait en 
sorte que : 

http : //livres . exemple . org/b/3j 7is . html 
force le serveur a renvoyer du HTML, tandis que : 

http : //livres . exemple . org/b/3j 7is . j son 
renvoie toujours du JSON (on pourrait alors avoir : 

http : //livres . exemple . org/b/3j 7is . j son?callback=myCallback 
pour supporter le JSONP). 



46 



CHAPITRE 5 - CONSTRUIRE UNE PLATEFORME : FOURNIR DES APIS 

Bon, soyons concrets. A quoi pourrait ressembler une de ces pages JSON ? 
Restons un moment sur notre exemple du livre. On peut imaginer une page sur un 
livre qui ressemblerait a quelque chose comme qa : 

{ 

'id': '3j7is', 

'titre' : 'The ABC book' , 

'mention_resp' : 'designed and cut on wood, by C. B. 
Falls. ' , 

'pagination': '30 p., ill. en coul. ' , 

'description' : "Un chef-d'oeuvre toutes epoques 
confondues, et un classique dans son domaine, ce gros et 
bel abecedaire de l'artiste renomme C. B. Falls seduit et 
enchante les enfants depuis plus de quarante ans. M. Falls 
a congu ce livre pour sa petite fille de trois ans, qui 
voulait un gros livre avec beaucoup d' images. Les 
illustrations sont gravees sur bois et imprimees depuis 
des plaques de quatre couleurs, et l'artiste a 
personnellement supervise leur reproduction. 

L'imagination des petits et des grands est laissee libre 
de capturer le familier par ses propres moyens de 
reconnaissance, dans un medium nouveau et ancien ou la 
couleur n'a pas obscurci le contour ni joue trop de tours 
a la nature . ", 

'editeur': 'Doubleday, Page & company', 

'auteurs': [{'id': '0L115179A', 'nom': 'C. B. Falls'}], 

} 
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Et si votre site autorise les gens a mettre a jour les pages sur les livres, vous 
pourriez imaginer supporter des requites PUT sur cette URI qui autorisent les 
gens a envoyer une nouvelle version de l'objet JSON. Vous l'encoderiez et 
effectueriez la mise a jour. 

Ou, si vous laissez simplement les gens commenter les livres, vous pourriez les 
laisser envoyer en POST de simples donnees JSON vers la mime URI ou les 
commentaires sont envoyes d'habitude. 

En fait, si vous le voulez vraiment, vous pourriez simplement les laisser envoyer 
en POST des donnees de formulaire et les encoder de la mime fa^on que vous le 
feriez pour des donnees saisies dans un navigateur web. Puis vous pourriez leur 
indiquer le succes ou l'echec de la manoeuvre par le biais des codes d'erreurs 
HTTP - une erreur 500 leur indiquerait un echec, alors qu'un code 303 See Other 
- une redirection vers la page de resultat de la requite - signifierait une reussite. Et 
quand ils suivraient la redirection et recupereraient la page, celle-ci pourrait aussi 
negocier son contenu en JSON. 

*** 

Tres bien, il est temps maintenant d'aborder un sujet sensible. Je me suis retenu la- 
dessus, mais a un certain moment, cela devient inevitable. Oui, j'ai peur qu'il soit 
temps de parler de RDF. 

Voyez-vous, tout ce true JSON e'est formidable pour ecrire des petits scripts sur 
des clients qui parlent a d'autres scripts sur des serveurs, mais laisse un peu a 
desirer quand on travail a l'echelle du Web. II est difficile d'imaginer, par 
exemple, construire des outils vraiment utiles qui fonctionnent a travers 
differentes APIs JSON, a la fa^on des navigateurs web qui fonctionnent a travers 
des pages HTML de toutes sortes. Chaque API JSON a sa propre representation 
interne, ses conventions et ses protocoles, ce qui implique qu'on doive ecrire un 
code specifique pour traiter avec chacune d'entre elles. 

C'est la qu'intervient RDE L'idee directrice est simple : et si on avait un format 
qui fait aux donnees ce que HTML fait aux documents - leur fournir une 
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representation unique et coherente qui supporte la nature hypertextuelle du Web. 
Ca n'est probablement pas clair du tout, alors regardons quelques exemples. 

Les documents RDF sont tres simples - ils sont composes de « triplets », des 
phrases simples avec trois parties : un sujet, un verbe (appele predicat), et un objet. 
Prenons un morceau de notre exemple plus haut, a savoir que le livre dont PID est 
3j7is a pour titre « The ABC book » - en RDF, le sujet serait « 3j7is », le verbe 
« titre » et l'objet la chaine « The ABC book ». 

Seulement, RDF est pense pour fonctionner a l'echelle du Web, done au lieu de 
termes vagues comme « titre », tout a un URL Comme dans : 

<http : //livres . exemple . org/b/3j 7is#it> 
http://www.w3.Org/1999/02/22-rdf-syntax-ns#label 
"The ABC book" . 

(Ces signes « # » sont la pour caracteriser le fait que nous parlons du concept 
decrit dans la page web, et pas de la page elle-meme.) 

Bien sur, taper toutes ces URLs a chaque fois fait vieillir vite, done nous avons 
tendance a les abreger : 

©prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax- 
ns#> . 

<http : //livres . exemple . org/b/3j7is#it> 
rdfs: label 
"The ABC book" . 
Voici une traduction rudimentaire du JSON d'au-dessus en RDF : 
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©prefix : <http://livres.exemple.0rg/api/schema#> . 

<http : //livres . exemple . org/b/3j 7is#it> 

:titre 'The ABC book' ; 

:mention_resp 'designed and cut on wood, by C. B. Falls.'; 
: pagination: '30 p., ill. en coul.'; 

:description "Un chef-d'oeuvre toutes epoques confondues, 
et un classique dans son domaine, ce gros et bel 
abecedaire de l'artiste renomme C. B. Falls seduit et 
enchante les enfants depuis plus de quarante ans. M. Falls 
a congu ce livre pour sa petite fille de trois ans, qui 
voulait un gros livre avec beaucoup d' images. Les 
illustrations sont gravees sur bois et imprimees depuis 
des plaques de quatre couleurs, et l'artiste a 
personnellement supervise leur reproduction. 

L'imagination des petits et des grands est laissee libre 
de capturer le familier par ses propres moyens de 
reconnaissance, dans un medium nouveau et ancien ou la 
couleur n'a pas obscurci le contour ni joue trop de tours 
a la nature . " ; 

:editeur 'Doubleday, Page & company'; 

: auteur <http : //openlibrary . org/a/0L115179A#it> . 

<http : //openlibrary . org/a/0L115179A#it> 

:nom "C. B. Falls". 

En plus d'utiliser invariablement des URIs, RDF a quelques fonctionnalites 
vraiment chouettes. En premier lieu, s'il y a quelque chose que Ton souhaite 
souvent faire avec des donnees, c'est de les combiner, et RDF rend ca tres facile. 
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Pour combiner deux documents RDF, on se contente de les concatener - qa n'est 
qu'une liste de faits ; deux listes de faits ensemble font une longue liste de faits. Ca 
n'est pas aussi simple en JSON, sans parler du XML. 

Une autre belle fonctionnalite de RDF est que qa rend facile la concordance entre 
formats. La conversion entre deux formats JSON requiert tout le temps du code, 
mais avec RDF vous pouvez simplement publier un autre document RDF qui 
explique la table de concordance, comme : 

rdfs: label = :titre. 

De cette fa^on, un logiciel qui connait « rdf:label » sait qu'il peut utiliser la 
propriete « :titre » de la meme maniere. 

RDF a toutes ces fonctionnalites sympas, mais a un gros defaut : qa n'est en rien 
aussi simple a utiliser que JSON. Comme XML, qa a son propre modele de 
donnees, ce qui implique d'ecrire un code specif ique pour naviguer entre sa fa^on 
de voir le monde et la votre. II existe quelques outils et techniques pour compenser 
cela (comme mon propre rdftrampt 13 ), qui essaye de faire plus ressembler RDF a 
des objets Python normaux) mais qa reste un serieux probleme. 

Le monde de RDF a essaye de remedier a cela en ecrivant des solutions de 
remplacement RDF pour tous les outils existants dans monde des logiciels : des 
bases de donnees RDF, des langages de programmation RDF, des systemes de 
requete RDF, des navigateurs RDF, des moteurs d'inference RDF, et ainsi de suite. 
Si vous le voulez, il existe tout un monde de RDF dans lequel vous pouvez 
plonger. 

En fin de compte, cependant, j'ai peur que ce ne soit pas une strategie tres 
prometteuse - qa va etre difficile de creer des solutions de remplacement pour 
toutes ces choses qui soient aussi bonnes ou meilleures que les originales, et meme 
si on y parvient, les gens garderont un attachement sentimental aux autres. 



1 3 http ://www. aaronsw. com/2002/rdf tramp/. 
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Done a ce point, je categoriserais encore RDF comme une aspiration. Qa serait un 
beau format universel de publication - on pourrait faire beaucoup de choses avec - 
mais pour un travail de tous les jours, JSON est bien meilleur. 

Ceci dit, RDF est bien sur de tres, tres loin preferable a XML. 
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CONSTRUIRE UNE BASE DE DONNEES : 
REQUETES ET SAUVEGARDES 



Les APIs c'est bien et tout, mais elles sont plutot limitees : elles ne donnent de 
reponses qu'aux questions qu'on sait deja poser. Vous voulez en savoir plus sur le 
livre 3j7is ? Bien sur, je vais tout vous dire. Mais vous voulez savoir quels livres 
publies recemment partagent un auteur avec un livre publie il y a plus de cent ans ? 
C'est un peu plus complique. 

Mais, heureusement, pas impossible. II parait ridicule de proposer votre propre 
API qui pourrait repondre a toutes sortes de questions de ce type. Mais vous vous 
souvenez de ces langages de requete dont on s'amusait dans le dernier chapitre ? II 
s'avere que c'est exactement le genre de choses dans lequel ils excellent. 

Le langage de requete RDF officiel s'appelle SPARQL (SPARQL Protocol And 
RDF Query Language, protocole et langage de requete RDF - qu'on prononce 
« sparkeul »). Si vous etes familier de SQL, le langage standard de requete sur les 
bases de donnees, SPARQL vous semblera similaire, avec simplement RDF colle 
a tous les bons endroits. Voici comment on pose la question pre-citee en 
SPARQL : 
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PREFIX : <http://livres.exemple.Org/api/schema#> 
SELECT ?livrerecent, ?livreancien 
WHERE { 

?livrerecent :auteur ?auteur . 

?livrerecent : annee_publication ?anneerecent . 

FILTER ( ?anneerecent >= 2008 ) 

?livreancien :auteur ?auteur . 

?livreancien : annee_publication ?anneeancien . 

FILTER ( ?anneeancien <= 1908 ) 

} 

II y a beaucoup de choses ici, done allons-y doucement. D'abord, on declare 
simplement les prefixes de nos URIs, comme d'habitude. C'est juste un moyen de 
s'epargner de la saisie. Puis on dit qu'on veut se voir renvoyer les valeurs 
« ?livrerecent » et « ?livreancien ». En SPARQL, tout ce qui commence par « ? » 
est un substitut que le moteur de requete va chercher a remplacer avec quelque 
chose qui convient. 

La clause « WHERE » annonce des contraintes a propos de ce qui convient pour 
remplacer ces substituts. « ?livrerecent » doit avoir un auteur et une annee de 
publication, et cette annee de publication doit etre egale ou superieure a 2008. 
« ?livreancien » doit aussi avoir un auteur et une annee de publication - et, en 
outre, son auteur doit etre le meme que 1' auteur de « ?livrerecent ». Mais son 
annee de publication doit etre egale ou inferieure a 1908. 
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Maintenant, comme SPARQL est conc^u pour fonctionner a l'echelle du Web, vous 
n'avez pas besoin de garder cette requete a la maison. A la place, vous pouvez la 
pointer sur le systeme de recherche d'un autre serveur, qu'on appelle un SPARQL 
endpoint, ou une interface SPARQL. Vous n'avez peut-etre pas beaucoup 
d'informations sur les livres, mais livres.exemple.org en revanche en a 
probablement - vous pouvez lui faire chercher des choses qui correspondent a 
votre requete. 

Pour ce faire, vous prenez simplement la requete qu'on a genere au-dessus, et vous 
la collez dans une URL proprement formatee. Et - bourn ! - en retour vous arrive 
une liste de reponses. 

Et un autre aspect sympa de SPARQL est que, si on s'y prend bien, il permet de 
deployer les requetes a travers plusieurs interfaces SPARQL. Ainsi, par exemple, 
on peut imaginer ecrire une requete pour des livres dont les auteurs sont juifs. Les 
informations sur les livres et les auteurs peuvent etre obtenues depuis le serveur 
livres, pendant que Wikipedia (dont la version RDF est appelee DBPedia) peut 
nous informer sur la religion des gens. Bien sur, se debrouiller pour structurer ces 
requetes d'une telle maniere qu'elles ne prennent pas un temps infini est un projet 
de recherche en cours. 

Dans le meme temps, nous pouvons au moins aider ceux qui savent se debrouiller 
avec nos donnees et fournissant des sauvegardes en gros. La theorie, ici, est 
simple : il y a beaucoup de requetes, de fusions, et de visualisations que les gens 
vont vouloir realiser avec vos donnees, et qui sont impraticables avec quelque 
sorte d'API que ce soit, meme aussi sophistiquee que SPARQL. Done vous 
devriez tout aussi bien simplement leur donner une copie complete de votre jeu de 
donnees. 

Et la pratique est encore plus simple : vous prenez simplement le JSON que vous 
generez pour chaque objet de votre site, et vous le mettez dans un unique gros 
fichier. 

II se peut que vous soyez tente de le compresser, parce qu'il sera sans doute plutot 
gros. 
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Chapitre 7 

CONSTRUIRE POUR LA LIBERIE : DONNEES 
OUVERTES, SOURCES OUVERTES 



Notre histoire commence avec un bourrage papier. On etait en 1980 et le labo 
□"Intelligence Artificielle du MIT avait re^u une elegante nouvelle imprimante de 
chez Xerox. L'imprimante, cependant, avait une facheuse tendance a se bloquer, 
causant ainsi 1' accumulation les taches d'impression, et rien n'etait imprime avant 
que quelqu'un s'en aper^oive et supprime le bourrage. 

Pour Richard Stallman, un des programmeurs du labo AI, qa n'etait pas bien 
grave. Avec l'imprimante precedente, Stallman avait simplement modifie le pilote 
d'impression pour qu'il detecte les eventuels bourrages, et previenne toutes les 
personnes qui lui avaient envoye une tache d'impression. « Si vous receviez ce 
message, vous ne pouviez pas presumer que quelqu'un d'autre s'en occuperait », 
raconte Stallman. « Vous deviez aller jusqu'a l'imprimante. Une minute ou deux 
apres que l'imprimante soit tombee en panne, les deux ou trois personnes qui 
avaient re^u un message arrivaient pour reparer la machine. Generalement, sur ces 
deux ou trois personnes, une d'entre elles au moins saurait comment regler le 
probleme. » 
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Mais rimprimante Xerox etait differente : Xerox n' avait pas fourni au labo le code 
source de leurs pilotes d'impression. II n'y avait aucun moyen pour Stallman 
d'aj outer cette nouvelle fonctionnalite au pilote. Quand Stallman a demande le 
code a Xerox, ils ont refuse de le communiquer, en insistant sur le fait que c' etait 
un secret commercial important pour leur entreprise. Et quand Stallman trouva un 
etudiant de l'universite de Carnegie-Mellon qui avait eu acces a ce logiciel, 
l'etudiant refusa egalement d'en fournir une copie, en disant qu'il s'etait engage 
par contrat avec Xerox a ne pas le partager. 

Stallman etait outrage. Les logiciels informatiques etaient senses etre des outils au 
service des gens ; c'est pour cela que lui et ses collegues de labo passaient leur 
temps a ecrire des logiciels. Et la, par le biais d'une combinaison de cupidite et de 
restrictions legales, les gens etaient forces de souffrir parce qu'on les empechait 
d'ameliorer ces outils. 

Stallman voulut s'assurer que personne d'autre n'aurait a souffrir de cela ; il 
voulut construire un systeme d'ordinateur base sur des principes de liberte. En 
1984, il demissionna et annon^a le projet GNU. 

Stallman plus tard mit au clair que les logiciels libres etaient des logiciels qui 
garantissaient aux utilisateurs quatre libertes : 

0. La liberte d'executer le programme, pour tous les usages. 

1. La liberte d'etudier le fonctionnement du programme et de l'adapter a ses 
besoins. 

(le code source est necessaire pour cela.) 

2. La liberte de redistribuer des copies du programme pour pouvoir aider son 
voisin. 

3. La liberte d'ameliorer le programme et de distribuer ces ameliorations au 
public, pour en faire profiter toute la communaute. 
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(Encore une fois, le code source est necessaire pour cela.) 

« Je considere que la regie d'or requiert que si j'aime un programme je dois le 
partager avec d'autres personnes qui raiment. Je ne peux pas en bonne conscience 
signer un accord de non-divulgation ou un accord de licence de logiciel. Pour 
pouvoir continuer a utiliser des ordinateurs sans violer mes principes, j'ai decide 
de reunir un corpus suffisant de logiciels libres qui me permette de m'en sortir 
sans aucun logiciel qui ne soit pas libre. » 

Stallman a codifie ces libertes dans la licence publique generale GNU, ou GPL 
(General Public License). Si vous modifiez un bout d'un logiciel qui est sous 
licence GPL, et que vous le redistribuez, la licence implique que vous redistribuiez 
le code source gratuitement, et que vous autorisiez tous ceux qui regoivent une 
copie a en faire de meme. 

Depuis 1984, le systeme d' exploitation GNU (dont le parfum le plus populaire est 
GNU/Linux) a ete construit sous la licence GPL. Une etude de 2007 a montre que 
13% des serveurs et 1% des ordinateurs de bureaux etaient vendus avec 
GNU/Linux. Et tout le monde peut telecharger gratuitement l'integralite du 
systeme d' exploitation sur Internet. 

Le succes de GNU/Linux a entraine une montee en puissance du mouvement des 
logiciels libres, en meme temps que le mouvement « open source », qui distribue 
des logiciels et leurs codes sources sous des licences de copyright qui apportent 
quelques unes des libertes du logiciel. 

Le navigateur Mozilla Firefox, par exemple, est open source et represente en ce 
moment environ 15% du marche. De larges portions du systeme d' exploitation 
Mac OS X sont aussi en open source, dont Web Kit, le noyau de Safari, le 
navigateur de Mac OS X. 

Les mouvements de l'open source et du logiciel libre ont aujourd'hui construit des 
alternatives libres pour a peu pres tous les grands types d' applications 
informatiques, depuis le traitement de texte jusqu'aux jeux videos. Et pendant un 
moment, il a semble que le reve de Stallman etait devenu realite : on pouvait 
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veritablement continuer a utiliser les ordinateurs sans avoir de lois qui restreignent 
notre liberte - c'etait possible « de s'en sortir sans aucun logiciel qui ne soit pas 
libre ». 

*** 

Pendant ce temps, Tim Berners-Lee, un anglais vivant en France qui travaillait 
dans un labo de physique en Suisse, s'enervait devant les difficultes que 
rencontraient les physiciens pour partager des documents. Et done, en 1989, il 
sortit le World Wide Web, developpa les standards qui le font fonctionner, et 
fabriqua le premier navigateur web et le premier serveur web. 

Le pouvoir du navigateur etait sa flexibilite (ou, selon les termes du professeur de 
droit Jonathan Zittrain, sa « nature generative »). Tout comme un ordinateur 
classique vous permet d'utiliser n'importe quel programme, du lecteur audio a la 
calculatrice graphique, le navigateur web vous laisse voir n'importe quelle sorte 
de document. Un livre, un article de physique, ou des photos de chats avec des 
legendes rigolotes - le navigateur web s'en fiche ; il affiche tout ce que le serveur 
lui fournit. 

Ca semble etre un detail trivial aujourd'hui, mais c'etait un grand changement par 
rapport aux autres logiciels en reseau de l'epoque. Les programmes d'emails, par 
exemple, sont conc^is pour simplement afficher des emails - ils ont une interface 
enormement specialised pour composer des emails, trouver des emails, voir les 
emetteurs et les destinataires des emails, et classer des emails dans des dossiers 
differents. C'etait vrai aussi des logiciels de discussion, des logiciels de chat, et 
des autres bouts de logiciels qui communiquaient sur le reseau. 

Le Web etait different : il n'etait pas specialise dans un type particulier de contenu, 
mais vous laissait partager ce que vous vouliez. 

L' absence de specialisation du navigateur web a permis aux gens de deplacer cette 
specialisation vers le serveur web. Le serveur web traditionnel servait simplement 
des documents statiques que quelqu'un avait ecrit prealablement. Mais il s'avera 
rapidement clair qu'il n'y avait aucune raison que le serveur soit si limite. 
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Au lieu de simplement servir des documents prealablement composes, le serveur 
pouvait composer des documents « a la volee » des qu'ils etaient demandes. Ainsi, 
au lieu d' avoir seulement un document qui liste les restaurants qui ont des tables 
disponibles, on pouvait charger le serveur de contacter les differents restaurants, 
d'apprendre leurs disponibilites, et de construire une page avec les resultats. 

Et les utilisateurs, au lieu de demander passivement des documents pre-ecrits, 
pouvaient soumettre des requites au serveur et commencer reellement a interagir 
avec lui. Ainsi, ils pouvaient demander au serveur de reserver une des tables, et 
envoyer leurs noms et numeros de telephone avec cette requite. 

II en resulta que l'humble navigateur web commence rapidement a supplanter 
toutes les autres applications « specialises ». Au lieu d' avoir un programme 
special pour simplement lire des emails, les gens lisent leurs emails sur le Web. De 
la mime maniere, les groupes de discussion, les salons de chat, et les autres 
formes d'interaction sociale se sont deplacees dans le navigateur web. 

Mais les developpeurs de logiciels ont vite decouvert que, pour les creatures 
sociales comme nous les humains, tout a un composant d'interaction sociale. Par 
exemple, donner un titre et categoriser les photos que vous prenez pourrait 
sembler itre une activite manifestement solitaire. Pourtant, des sites comme Flickr 
ont demontre que les gens adorent commenter et categoriser les photos de leurs 
amis, ou mime d'etrangers, et que les gens, tout bien considere, prefereraient 
organiser leurs photos dans un programme qui les expose a d'autres personnes. 

Le resultat, c'est le phenomene recent « Web 2.0 », par lequel a peu pres tous les 
morceaux de rinformatique ont migre dans le Web et ete rendus sociaux d'une 
maniere ou d'une autre. Pour les photos et les videos, il y a Flickr et Youtube. Pour 
les infos, il y a des sites comme Digg et Reddit ou on peut soumettre, editer, et 
voter pour des informations. Les calendriers, les listes de taches, mime les 
collections musicales et les traitements de texte se sont tous transformes en 
applications web dynamiques et sociales. 

Les experts discutent maintenant d'un futur pas si lointain de « clients idiots » et 
de « cloud computing » ou les autres applications de l'ordinateur disparaitraient et 
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tout ce qui resterait serait le navigateur web. Et pour les gens qui utilisent des 
ordinateurs en libre-acces ou les cybercafes, ce futur est deja la. 

Pour certains, c'est une perspective excitante. Mais pour ceux, comme Stallman, 
concernes par les problemes de la liberte logicielle, c'est effrayant. Meme dans les 
jours sombres du pilote d'impression proprietaire, Stallman avait encore le controle 
sur l'ordinateur qui pilotait l'imprimante, meme s'il n'avait pas le code source pour le 
modifier. Mais avec une application Web 2.0, vous n'avez meme pas ^a. L'ordinateur 
qui fait tourner votre logiciel est enferme dans une ferme de serveurs loin d'ici. Vous 
pouvez seulement communiquer avec lui a travers votre navigateur web. 

Bon, cela apporte une certaine flexibilite. Les navigateurs web peuvent etre 
programmes pour bloquer les publicites ou pour extraire du contenu. Des modules 
comme Zotero et Greasemonkey permettent aux utilisateurs d'aj outer des 
fonctionnalites aux sites existants en interceptant et en modifiant les documents 
quand ils arrivent du serveur web. 

Mais c'est plutot une pale notion de la liberte, comme si on disait que les 
cinephiles ont le controle sur les films qu'ils voient parce qu'ils peuvent tenir des 
images devant l'ecran pendant qu'ils les regardent. 

Une autre option, bien sur, est de fournir des APIs. Ainsi, au lieu d' avoir a cliquer 
manuellement sur le bouton « Acheter » d'une page Amazon pour acheter un 
nouveau lot de rasoirs, avec une API Amazon, vous pouvez avoir un programme 
qui achete automatiquement les rasoirs pour vous chaque mois. 

C'est sans aucun doute pratique, mais encore une fois, c'est une bien pale notion 
de liberte comparee aux quatre libertes apportees par le logiciel libre. Si Amazon 
etait vraiment libre, vous ne seriez pas simplement capable d'automatiser votre 
usage de 1' application, vous seriez capable de changer comment 1' application 
fonctionne veritablement. 

La solution evidente a ce defi est simplement de diffuser le logiciel sur le serveur 
Web sous la licence GPL ou sous une autre licence de logiciel libre. Ainsi, tout le 
monde pourrait telecharger une copie et la modifier tout son soul. Et une nouvelle 
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version de la GPL est sortie, 1' AGPLv3, qui requiert que les personnes qui utilisent 
le logiciel dans leur application web rendent leur logiciel librement disponible 
pour les utilisateurs de 1' application. 

Mais seule une application completement asociale consiste purement en un 
logiciel. La grande majorite d'entre elles sont interessantes parce qu'elles vous 
donnent acces a des donnees auxquelles ont aussi contribue d'autres utilisateurs. 
Par exemple, le logiciel qui laisse les gens editer des pages web est sans doute la 
chose la moins interessante concernant Wikipedia. La raison pour laquelle ce site 
est si populaire, c'est parce que beaucoup de gens ont accumule leur savoir dans 
ce logiciel. 

Wikipedia s'est attele a ga en allant un pas plus loin - non seulement le code 
source est libre, mais les donnees le sont aussi. N'importe qui peut telecharger une 
copie de la base de donnees de Wikipedia (a 1' exception des informations 
personnelles des utilisateurs) et commencer sa propre imitation de Wikipedia 
basee sur roriginale. Et on peut modifier sa copie du logiciel de Wikipedia pour 
en adapter le fonctionnement a ses propres gouts. 

C'est beau en theorie, mais en pratique, bien sur, personne ne le fait. Meme si 
votre version de Wikipedia etait pleine de fantastiques nouvelles fonctionnalites, il 
serait tout de meme presque impossible de trouver quelqu'un pour l'utiliser. Les 
gens utilisent Wikipedia parce que c'est la que tous les autres sont ; il est 
pratiquement impossible de faire bouger tout le monde. 

Pour Wikipedia, le probleme est quelque peu attenue par le fait d' avoir une sorte 
de controle pseudo-democratique sur le site. Wikipedia est pilote par un bureau elu 
par (une faible fraction de) ses utilisateurs, et le bureau a un pouvoir nominal de 
controle sur le logiciel et les modifications qui y sont faites. Mais ne ressemble 
encore que de loin a la liberte que les utilisateurs de GNU/Linux ont dans le 
monde non-connecte. Presenter sa candidature, etre elu, puis soutenir vos 
modifications devant une bureaucratie retive au changement est beaucoup plus 
complique que modifier quelques fichiers du code source sur son ordinateur puis 
redemarrer. 
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Et done, les partisans les plus acharnes de la liberte logicielle proposent que nous 
renvoyions le balancier depuis l'informatique sur un serveur centralise vers son 
monde de depart ou nous faisions tous tourner nos applications sur nos machines 
locales. Seulement cette fois, au lieu d'etre des applications qui n'utilisent pas le 
reseau ou qui ne parlent qu'a un serveur distant, ce seraient des applications pair- 
a-pair, peer-to-peer, qui chercheraient d'autres utilisateurs et qui interagiraient 
directement avec eux. 

De grandes enjambees ont ete faites dans la construction de logiciels pair-a-pair, 
en raison, pour une part non negligeable, de l'interet massif pour l'utilisation de 
cette technologie dans le partage de musique sans se faire attraper par les 
representants de la loi. Mais, particulierement quand on la compare a la 
technologie centree sur les serveurs du Web 2.0, la technologie pair-a-pair en est 
encore a ses balbutiements. Ecrire une application sociale qui serait pair-a-pair est 
a peu pres mille fois plus complique qu' ecrire le meme programme en tant 
qu' application web. 

Pourtant, les logiciels pair-a-pair, si on arrivait a les faire fonctionner, pourraient 
presenter le meilleur des deux mondes : la liberte de modifier comment le 
programme fonctionne sur notre ordinateur local, aussi bien que la possibilite de 
partager et de collaborer avec d'autres sur Internet. Et done, pour ceux qui se 
soucient de liberte (comme pour ceux qui se soucient d'echanger de la musique), 
semble etre une voie importante a approfondir. 

Dans le meme temps, meme si, a l'instar de la question de comment formuler des 
requetes sur de nombreuses bases de donnees SPARQL, le probleme de la liberte 
des applications web reste irresolu, vous pouvez toujours commencer. L'Open 
Knowledge Foundation, un groupe qui promeut les bases de donnees librement 
partagees, a propose une definition du service logiciel ouvert (14) . La definition 
codifie essentiellement les principes evoques plus haut : 

1. Rendez votre code disponible en tant que logiciel libre ou open source. 

2. Rendez vos donnees disponibles en tant que connaissances ouvertes. 

14 http ://opendef inition. org/sof tware-service/. 
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Pour les logiciels libres / open source, il y a la liste officielle de POpen Source 
Initiative et de la Free Software Foundation pour dire si votre licence est 
suffisamment libre ou ouverte. Les exemples incluent la licence Expat/BSD, la 
GPL, etc. L'Open Knowledge Foundation, similairement, liste une serie de 
licences, incluant certaines licences Creative Commons, la licence GNU Free 
Documentation, et ainsi de suite. 

C'est P aspect legal, mais P aspect technique est tout aussi simple : fournissez un 
entrepot de code source pour tout votre code, et des sauvegardes SQL pour toutes 
vos donnees. 

Bien sur, cela laisse de nombreuses questions ouvertes. Que faire des donnees 
personnelles, par exemple ? Mon sentiment personnel est que chacun devrait etre 
autorise a telecharger ses propres donnees et toutes les donnees qui lui sont 
accessibles par le biais de Pinterface web - par exemple, les donnees concernant 
leurs amis Facebook. 

Et il y a plein de place pour experimenter la conception de sites qui promeuvent 
plus de controle democratique. Peut-etre que vous pourriez essayer des choses et 
m'en parler, et ils les ajouteront a la seconde edition de ce livre. 
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Conclusion : un Web semantique ? 



Bon, nous avons traverse pas mal de choses ensemble, vous et moi. Nous avons 
construit une application depuis ses humbles URLs jusqu'a ses pompeuses 
pretentions democratiques. Le long du chemin, nous avons rendu son monde sur 
pour les robots, les systemes de requetes, les chercheurs, et Richard Stallman. 
Mais comment passer de cette sorte de page web a la grande vision de Web 
semantique dont on a tant entendu parler ? 

Commen^ons par realiser que rien que d'etre sur le Web est quelque chose de 
fascinant. Les URLs fournissent un schema unifie d'adressage pour tous les 
documents - ce qui est plutot miraculeux. Imaginez essayer d'expliquer aux gens 
d'antan ces mots incroyables que vous pouvez donner a quelqu'un, qui peut les 
amener chez lui, les entrer dans une boite qu'il a sur son bureau, et obtenir 
exactement 1' article, 1' image ou la video que vous evoquiez. Pour une generation 
pour qui la recuperation d'information c'etait se rendre a la bibliotheque locale, 
remplir quelques formulaires, et attendre quelques semaines pendant qu'ils 
essayent de comprendre ce que vous cherchez et de mettre la main dessus, 
represente un sacre changement. 



67 



Aaron Swartz - Un Web programmable 

Mais REST va encore plus loin. En rendant les documents accessibles par les 
moteurs de recherche grace a un protocole standard, vous n'avez meme plus 
besoin de connaitre la bonne URL de ce que vous cherchez. Tapez simplement 
quelques mots choisis dans Google et bourn ! en retour vous arrive la chose que 
vous vouliez, en un quart de seconde. 

Bien sur, n'est pas que Google ; REST rend possible une tapisserie 
interconnectee qui supporte tout, des navigateurs web aux editeurs web, jusqu'aux 
proxies intermediates de traduction. 

Un acte difficile a suivre. Et ensuite vint la possibilite d'obtenir non seulement des 
documents depuis ces serveurs lointains, mais aussi des donnees. En important et 
exportant des donnees brutes, nous avons rendu possible de se passer des 
programmes, en instaurant un marche a peu pres libre de produits en competition, 
ce qui cree un surplus massif de consommateurs. Allez nous ! 

Et nous ne nous sommes pas arretes la. Se contenter de laisser les utilisateurs 
emporter leurs donnees a la maison, c'est de la petite biere compare au partage des 
donnees avec le monde entier (imaginez un monde entier de gens chez eux avec 
leur petite biere de donnees). C'est pourquoi le Web a invente les APIs, qui nous 
permettent de partager des donnees avec tous ceux qui pensent pouvoir en faire 
usage. 

La, nous ne sommes plus un simple site web, qui envoie des pages au navigateur, 
en fournissant une liste de type « voir aussi » presentant d'autres pages qu'on 
pourrait visiter. On echange les donnees elles-memes d' application a application, 
rendant possible un monde nouveau de melanges et d' applications intelligentes. 

C'est un concept entierement nouveau de tapisserie - une tapisserie de donnees et 
non plus de documents. Les documents ne peuvent pas vraiment etre fusionnes, 
integres, et recherches ; ils servent plutot d'instances isolees destinees a etre vues 
et revisees. Mais les donnees sont proteiformes, capables d'endosser la forme la 
plus a meme de repondre a vos besoins. 

Mais avec la variete de nos besoin qui s'elargit, nous avons besoin d'un meilleur 
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moyen pour parvenir aux donnees qui nous seront les plus utiles. C'est la 
qu'interviennent nos requetes et nos sauvegardes. Nous ne sommes plus entraves 
par le fait d'etre seulement capables de poser les questions que les programmeurs 
d'un site avaient prevues et prises en compte ; maintenant nous pouvons poser les 
questions que nous voulons quelles qu'elles soient, ou accomplir des procedures 
qui ne peuvent meme pas etre formulees comme des questions. En combinant ces 
sauvegardes de differentes sources de donnees, les possibilites sont infinies. 

Mais a partir de la, ou allons-nous ? 

Assurement, la premiere etape est de prendre les volumineuses sauvegardes que 
nous avons faites, et de les charger dans une unique grosse base de donnees. Et, 
bien sur, on a commence a voir des gens faire qa, depuis les projets de recherches 
jusqu'aux compagnies commerciales comme Metaweb avec Freebase. Freebase 
est une enorme base de donnees collaborative editable sur le Web de type RDF, 
pre-remplie de donnees extraites de Wikipedia et de nombreuses autres sources, et 
completee avec les contributions d'utilisateurs divers. Freebase est encore plutot 
petite, mais leurs objectifs sont ambitieux - creer une base de donnees qui 
combine de multiples sources differentes et la mettre a disposition en tant que 
support pour des gens qui veulent construire des applications plus intelligentes. 

Dans P ideal, bien entendu, les applications intelligentes ne seront pas dependantes 
d'un seul site commercial, comme Freebase, mais fusionneront et combineront les 
connaissances issues de divers sites dissemines sur le Web, en se depla^ant et en 
ramassant des informations plus utiles, et en decidant quelles parts de celle-ci elles 
peuvent croire. 

Deja, nous pouvons voir des choses de ce genre dans des projets de recherche. Un 
des outils du Web semantique les plus excitants est un programme appele cwm, 
bricole et assemble entre deux reunions (ou durant celles-ci) par Sir Tim 
Berners-Lee en personne. Cwm (qu'on prononce coum) est un des programmes 
les plus etonnants que j'aie vus ; c'est un veritable couteau-suisse pour les 
donnees, entierement con^u autour de RDF. 

Bien sur, il remplit toutes les taches de base - lire et ecrire des fichiers RDF dans divers 
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formats, combiner plusieurs fichiers, afficher tous les resultats dans un joli format. 

Naturellement, il peut aussi chercher dans les donnees obtenues pour repondre a 
vos question d'une fagon tres similaire a celle de SPARQL. 

Mais cwm va un pas plus loin. II ne se contente pas de chercher dans les donnees ; il 
reflechit a leur propos. Cwm peut suivre des regies logiques ; prenez celle-ci, par 
exemple : 

{ ?x a :Man } => { ?x : mortality : mortal } . 

(Si quelque chose est un homme, alors il est mortel.) Chargez cela dans cwm, en 
meme temps que : 

: Socrates a :Man . 

(Socrate est un homme.) Et il va logiquement en deduire que Socrate est mortel. 
De telles series de regies ont evidemment toutes sortes d' utilisations possibles, 
depuis les jeux de societe logiques jusqu'a la veritable programmation. Mais une 
utilite manifeste est de fournir des conversions entre differents formats RDF. 
Imaginez deux schemas : « joe: », qui a « petit », « moyen », et « grand » et 
« Starbucks: », qui a « short », « tall », « grande », et « venti ». Maintenant, nous 
pouvons simplement ecrire quelques regies pour les convertir entre eux : 

{ ?x joe:taille joe: petit } <=> { ?x Starbucks : taille 
Starbucks: tall } . 

{ ?x joe: taille joe: moyen } <=> { ?x Starbucks : taille 
Starbucks : grande } . 

{ ?x joe: taille joe: grand } <=> { ?x Starbucks : taille 
Starbucks : venti } . 

Chargez ces regies dans cwm, avec les donnees dans un format, et cwm va 
« reflechir » la-dessus et recracher les donnees dans 1' autre format. 
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Mais cwm peut faire beaucoup plus que de la deduction logique de base. II a aussi 
une grande variete de fonctionnalites integrees, qui peuvent tout faire du 
traitement mathematique a la cryptographie avancee. Avec elles, et quelques 
regies intelligentes, vous pouvez meme ecrire des programme entiers en utilisant 
cwm. 

Accessoirement, rien de tout ^a n'est neuf - a peu pres tous ces trues etaient ecrits 
en 2001. 

Cwm est egalement assez malin pour aller sur le Web et trouver plus de regies 
comme celles-ci, en farfouillant a travers les pages web a la recherche de quelques 
morceaux de RDF qui le rendraient plus malin encore. II peut suivre les liens et les 
URLs et en recuperer plus de donnees, en surfant sur le Web comme un adolescent 
qui s'ennuie surfe sur le Web pour se distraire. 

Si ga vous interesse d'essayer ce procede par vous-meme, vous pouvez tester le 
dernier projet de Tim : le Tabulator. C'est une petite extension pour votre navigateur 
web qui lui permet de voir des documents RDF en plus des pages web normales. 
Soudain, les documents ne sont plus de simples listes de balises ennuyeuses ou de 
texte, mais un sender de liens cliquables que vous pouvez suivre au gre de vos envies 
(et, avec les versions ulterieures, vous pouvez meme editer certains des champs). 

On peut imaginer des outils comme cwm et Tabulator installes derriere les 
applications que nous utilisons tous les jours, et les enrichissant des connaissances 
tirees des etendues du Web. 

Parce que c'est la veritable idee derriere le Web semantique : laisser les logiciels 
utiliser rimmense genie collectif integre dans les pages qui y sont publiees. 
Pensez a tous les cas ou les logiciels utilisent des APIs ou des bases de donnees : 
votre correcteur d'orthographe interroge un site web pour trouver la definition 
d'un mot, votre carnet d'adresse cherche a savoir si vos amis sont en ligne, votre 
agenda telecharge une page pour vous faire suivre un evenement a venir. 
Maintenant, imaginez si ces programmes n' etaient pas limites a un site en 
particulier, mais pouvaient aspirer 1' intelligence d 'Internet en liberte. 
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Votre correcteur d'orthographe peut suggerer des mots lies ou alternatifs, ou 
simplement se maintenir aii courant de l'argot moderne. Votre carnet d'adresse 
peut vous dire ou sont vos amis dans l'instant, et ce qu'ils ont fait dernierement. 
Votre agenda peut garder un oeil sur les evenements qui pourraient peut-etre vous 
interesser. 

C'est facile de se moquer de ce genre de visions. Mon pere, apres avoir vu ce 
genre de demonstration, demandait toujours « Mais pourquoi ton grille-pain a 
besoin de suivre la bourse ? ». Et, si qa se trouve, ga n'en vaut pas la peine. Mais le 
Web semantique est fonde sur un pari, le pari que dormer au monde des outils pour 
collaborer et communiquer facilement va ouvrir des perspectives si formidables 
que nous ne pouvons qu'a peine les imaginer aujourd'hui. 

Bien sur, qa a Fair un peu dingue. Mais qa a paye la derniere fois qu'ils s'y sont 
risque : on a fini avec un petit true appele le World Wide Web. Voyons s'ils 
peuvent encore le faire. 
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Cette oeuvre courte est le premier jet d'un manuscrit d'Aaron Swartz, redige pour 
la collection « Synthesis Lectures on the Semantic Web » a l'invitation de son 
directeur, James Hendler. Malheureusement, le livre n'a pas ete termine avant le 
deces d'Aaron en janvier 2013. En son hommage, le directeur et l'editeur publient 
l'ceuvre numerique gratuitement. 

Extrait de I'introduction de I'auteur : 

« ... nous commencerons par essayer de comprendre 1' architecture du Web - ce qui 
marche bien et, a 1' occasion, ce qui ne marche pas, mais surtout pourquoi il est fait 
comme qa. Nous allons apprendre comment il autorise a la fois les utilisateurs et 
les moteurs de recherche a coexister pacifiquement tout en supportant tout, du 
partage de photos aux transactions financieres. 

Nous continuerons en reflechissant a ce que signifie construire un programme au 
sommet du Web - comment ecrire un logiciel qui sert equitablement autant son 
utilisateur immediat que les developpeurs qui veulent construire par-dessus lui. 
Trop souvent, une API est boulonnee au dessus d'une application existante, apres- 
coup ou comme un morceau completement different. Mais, comme nous le 
verrons, quand une application web est concue proprement, les APIs en decoulent 
naturellement et leur maintenance ne requiert que peu d' efforts. 

Puis nous nous interesserons a ce que signifie pour votre application de n'etre pas 
seulement un autre outil pour les gens et les logiciels, mais une partie de l'ecologie 
- une section du Web programmable. Ce qui implique d'exposer vos donnees a 
etre interrogees, et copiees, et integrees, et ce meme sans autorisation explicite, au 
sein du plus grand ecosysteme de logiciels, tout en protegeant la liberte des 
utilisateurs. 

Enfin, nous conclurons avec une discussion sur cette expression tres galvaudee : 
« Web semantique », et nous tacherons de comprendre ce qu'elle signifie 
vraiment. » 



